Embedded Java Research

Geoffrey Beers
Peter Jantz
December 18, 2001
 Advantages of the Java
Technology Model
 Simplicity
– Easier language to learn than traditional C/C++ and still has
object-oriented methodology.
 Security and Safety
– Java programs have more robust security checking, with the
RTE creating a “sandbox” where applications can run
safely.
– Lack of pointers eliminates direct memory access
 Portability and Robust Distribution
– Applications can be easily developed on desktop systems
and ported, with minimal effort, to target device.
– “Write-once, run anywhere” mentality.
Disadvantages of Embedded Java
 Huge speed disadvantage. Interpreted Java code is
still 5-10 times slower than a similar C
application.
– Improvements made to JVM technology have enhanced
this over the years.
– Often based on how the application is written
» A well-written Java program can out-perform a poorly written
C program
– For embedded applications do we really need to
interpret code, or can we use native-compiled code?
Disadvantages of Embedded Java
 Embedded Java technology still relatively new and
industry support has been slow to catch-on.
 Biggest disadvantage: Lack of RTOS support or
standard
– Early embedded Java applications were very similar to
conventional desktop programs. Fine for some apps,
but deadline control and interrupt handling are
necessary.
– Great improvement in this genre since 1998.
Real-Time Specification for Java
Guiding Principles
 Applicability to particular Java environments.
– Do not include specs that restrict use to a particular
Java environment.
 Backward compatibility
– RTSJ shall not prevent existing, non real-time Java
programs, from executing on implementations of the
RTSJ.
 “Write once, run anywhere” mentality should be
followed as much as possible.
RTSJ Guiding Principles (cont.)
 RTSJ should address real-time system practice and
allow for the incorporation of advanced features in
the future.
 Predictable execution as first priority in all
tradeoffs.
– May come at expense of general-computing
performance, but will allow for greater real-time
integration.
 No syntactic extension
– RTSJ will not introduce new keywords or other
syntactic extension to the Java language.
Real-Time Specification for Java
 Finalized in November 2001.
 Standard specification for garbage
collection, memory management, and
task/thread control.
 Additional classes and extensions to
standard Java JDK.
– However, no new syntax was necessary.
 javax.realtime Package
 Real-time specification provides
modifications to the Java Language Spec.
and JVM Spec.
 New APIs to enable the creation,
verification, analysis, execution, and
management of real-time Java threads.
 New APIs in a standard extension package,
javax.realtime.
 Seven Areas of Enhancement
 Thread scheduling and dispatching
 Memory management
 Synchronization and resource sharing
 Asynchronous event handling
 Asynchronous transfer of control
 Thread termination
 Physical memory access
 Four Memory Areas
 Scoped Memory
– Objects have lifetime defined by syntactic scope.
 Physical Memory
– Objects created within specific physical memory
regions having certain characteristics.
 Immortal Memory
– Objects cannot be destroyed; once allocated they stay
until the end of the application.
 Heap Memory
– Objects represent an area of memory on the heap.
 Asynchronous Events
 Some internal or external event that
happens.
– Not all real-life events are predictable in time
and frequency.
 System needs to respond to the changing
environment.
– Ability of real-time systems to react to the
events requires reliable asynchrony techniques.
 Major Platforms Supported
 Operating Systems
– Windows CE
– Linux
 Processors
– PicoJava – Sun’s Java Processor
– StrongArm
– MIPs
– Intel
 Java and Embedded Linux
 Java does I/O by opening files which are the
Linux device drivers (ex: /dev/mem). Java
can seek in addition to read, write and open.
 Bootstrapping allows Linux to load necessary
drivers and networking files and start running
the JVM.
 Standard Linux distributions with networking
support require lots of memory.
 Improving Performance
 Java bytecode programs are typically 10
times slower than programs written in C or
C++.
 How well the program is written is more
important. A well-written Java program can
equal the efficiency of an average-written
C/C++ program.
 Interpreting code uses less ROM.
 Compilation into Native Code
 AOT (Ahead of time)
 JIT (Just in time)
 Dynamic Compilation
 AOT Compilation
 Similar to C compilers
 Tends to create large executables
 Need to re-compile for different platforms
or when loading a different class
 Can compile everything including class
libraries
 JIT Compilation
 Machine independent
 Higher startup cost
 Not ideal for embedded systems
– Requires fast CPU, lots of virtual memory and
a fast disk drive for paging
 Dynamic Compilation
 Dynamically compiles code that is being
used more frequently
 Typically uses JIT compilers
 Doesn’t require virtual memory, adaptable
to available system memory
 Isn’t guaranteed to meet timing constraints
– Applications can change the compiler’s thread
priority for greater predictability
 Other Methods to improve
Performance
 Static Linking - place bytecode into ROM
 Re-write bytecode interpreter in assembly
language
 Use a Java Chip
 Conclusions and Summaries
 Recent advances in embedded Java technology
and advent of RTSJ are allowing real-time
capabilities and possibilities in the Java world.
 Many current embedded Java systems are non
real-time or a limited subset of RTSJ principles.
 Sun’s advancements and broad range of
distribution environments make embedded Java
programming much simpler and more robust.