De Paul University SE691 Yaron Benita

1

Developing Real Time Embedded Software using
Java Technology Architecture

• De Paul UniversitySE691Yaron Benita

2
Why Java ?

• Java is Platform independent.
• Java language is simple an easy to maintain.
• Eliminate most of the troublesome features
  existed in C. ( Data types have fix size,
  Automatic bounds checking, string supports, true
  or false.(, ) )
• Java is an Object Oriented language. Use of
  encapsulation, polymorphism and inheritance.

3
Why Java?

• Automatic Garbage Collection, which eliminates
  memory, leaks
• A build-in library for multithreading that
  provides a unified thread and synchronization
  API.
• A mechanism for exception handling.
• Support for networking.

4
Why use something else ?

• No direct access to hardware.
• Java has no pointers
• There is no bytecodes to access a physical
  address.
• Inefficiencies.
• bytecode interpretation is slower then C/C.
• Garbage collection requires processor time.
• Interpreter slows the execution time.
• Unpredictability.
• Garbage collector could preempt a real time task
  .
• Code size.
• 1 Mbytes of ROM, and several hundred kilobytes of
  RAM. ( JVM and class libraries.)

5
Java usage model.

• Location of the bytecode. ( host,target)
• Processor in which the program is executed.(host,
  target).
• Model 1 The bytecode is located in the Server,
  but executed in the host. (Applets).
• Model 2 The bytecode is located in the host, but
  executed in the Target. ( Results send to host,
  or effects on the embedded system)

6
Java usage model.

• Model 3 The bytecode is located in the target
  and executed in the target.
• The target does everything by itself. ( Pager,
  cell phones, PDA,.. )
• The JVM is part of the embedded system.
• Software written in Java and executed in an
  embedded processor. (Model 2 and 3)
• The application is located in the target, or
  downloaded over the network.

7
Java Virtual Machine.

• The JVM includes the execution engine, Dynamic
  class loader, Bytecode verifier ( optional ) and
  Garbage collector.
• The execution engine is responsible for the final
  translation of Bytecodes to native opcodes.
• The different types of engines are Bytecode
  interpreter , Just-in-Time compiler and Hybrid
  complier.

8
Execution Engines

• Bytecode Interpreter translate every bytecode
  to the native opcode, and then execute the native
  opcode. ( 10 times slower, portable.)
• Just-In-Time compiler - Translate a method into
  native opcode and saves the translation in the
  RAM for future use. Future use of that method
  will be faster. ( Much faster, but the RAM usage
  is very high not an optimizing compiler)

9
Execution Engines

• Hybrid engine use the JIT compiler approach,
  but translate, optimize and save only methods
  with largest pay offs. The decisions are made
  based on methods statistics done on run time.
• Use less RAM space then JIT
• Sun HotSpot compiler.

10
Garbage Collection

• Mark and sweep algorithm Use in most JVMs.
• Do nothing until an allocation request failed.
• In case a request failed Update the heap, free
  the unused memory, and satisfy the allocation
  request.
• Continue the application execution.
• This algorithm is not deterministic, and stop the
  program execution for a long period of time.

11
Garbage Collection

• Incremental Garbage Collection This algorithm
  is more efficient, and increase the processor
  availability. ( some Real Time systems.)
• Runs as a separate task, with a priority less
  then real time tasks.
• Free unused memory incrementally, while the
  other task are still running. ( tri color,..)
• Priority may increase or decrease.
• Decrease the chance of missing deadlines.
• Reduce processor availability.

12
Garbage Collection.

• Use of a special memory module to handle the
  memory allocation.
• Bounded worst case of allocation and object
  access time.
• On average the allocation an access time are
  slower then other approaches.

13
Code Size

• In order to reduce the code size needed for a
  Java program Sun came up with 3 Java API
  packages, which create 3 types of Java
  applications
• Standard Java the full set of class libraries.
• Personal Java a sub set of Standard Java. (
  PDA, cell phones, etc.)
• Embedded Java - A subset of Personal Java API
  that is better suited to the resource constrains
  environments. The idea is to include only the
  classes that are necessary for the application. (
  Memory constrains devices.)

14
AOT- Ahead of Time compilers.

• The Problems with a typical JVM are
• It is too big. ( Heap, JVM, class libraries,
  etc.)
• It is slow.( run time check, bytecode
  interpretation )
• Unpredictable Default garbage collectors.
• Solution Find a way to be able to compile a Java
  program into a native opcodes, prior to loading
  it to the target.
• This type of Java compiler is called AOT
  compiler.

15
AOT- Ahead of Time compilers

• Supports the traditional development model like
  C/C. (compile, link and then locate in ROM.)
• Significant performance improvement. ( 1 to 1.5
  times C/C programs.)
• The overhead time is garbage collection and real
  time checks.( divide by zero, etc.)
• Make global optimization possible.
• Reduce run time overhead. ( bytecode translation,
  bytecode verifier and dynamic class loader.)
• Most of the AOT compilers can compile class
  files.

16
Java Native Interface.(JNI)

• Java provides a way to call native methods
  written in some other language.
• Work around some java limitation.( Memory access)
• Improve performance. ( assembly code.)
• Call some legacy code.
• Exa Public native void setMemAdd(0x3000)
• part of Java since SDK1.1.
• Javah generates C/C header files.
• The native method should be loaded via
  System.loadLibrary() command.

17
Other Technologies.

• Java Processor - designed by SUN and other IC
  manufactures.
• executes Java bytecodes directly.
• No need for run time translation.
• Less memory use, since there is no JVM.
• Direct hardware support for threads/synchronizatio
  n and garbage collection
• Class loader and OS are still needed.

18
Other Technologies.

• Smart cards 16K ROM, 8-bit integer, etc.
• Designed for highly constrains environments.
• Subset of language of Java language/bytecodes.
• No multithreading, optional garbage collection,
  class loader and byte verifier.
• Non of the standard libraries.
• Kjava Virtual Machine A smaller an more optimal
  JVM. ( 128-256k RAM, PalmOS).
• Makes the JVM features ( threads, long, float ),
  optional.

19
Demo results

• Run time measurements collected in the Router
  application. ( Win2000 platform)
• Program compiled using AOT compiler.
• Average run time 274.7475 millisecond.
• Total run time - 30494 millisecond.
• Program ran using standard JVM.
• Average run time 308 millisecond.
• Total run time - 27200 millisecond.
• AOT build process is very slow.

20
Questions !!!!!