Embedded Java Research

1. Embedded Java Research Geoffrey Beers Peter Jantz December 18, 2001

2. General Java Overview • Robust object-oriented language developed by Sun Microsystems in 1995. • Basic idea was to create a language that can run on any platform • Even early Java models and development considered the future of embedded system programming. • “Write-once, run anywhere” ideology.

3. } Java Platform Typical Hardware View of Java Applications

4. Embedded Java Application Environment Taken from Sun Microsystems

5. Embedded Java Application Environment • Unlike traditional Java packages, the Embedded Java environment is far more configurable. • Do we really need I/O? • What packages do we really need? • Is a GUI required? • Ability to have all standard JDK components (except Applet), with the ability to only use what is necessary.

6. 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.

7. 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?

8. 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.

9. Pouring Java into Embedded Device Development Some of the features that have made Java an excellent choice for desktop programming cause problems on an embedded system. Most of these problems have solutions as well as trade-offs. *Support for this has been greatly improved through RTSJ

10. Challenges of Embedded Java • Memory Requirements • Execution speed • Garbage collection and memory management • Real-time OS support

11. Typical Memory Requirements of Java Systems

12. Real-time Java Issues • Necessary to handle hard and soft deadline constraints. • Support for timely execution of tasks and interrupt routines • Thread priorities and locking • Garbage collection and the embedded model. • How do we know we’re not going to use the dynamic memory again?

13. Garbage Collection • Garbage collection (GC) is great idea for larger system development, but can create major problems in an embedded environment. • Major problem for hard real-time systems. • Early solution: Avoid GC altogether. • Allocate memory dynamically, but never delete. If it’s not needed again, waste space, but will be available if needed. • PERC handles GC rather well; RTJS also defines a GC standard.

14. Early Real-Time Considerations • Although Java had enormous potential as an embedded system development tool, the real-time issues were still a reality. • Ideally, needed a way to control garbage collection and optimize memory. • Considerations for real-time threads and scheduling models. • These considerations introduced as early as 1995.

15. Real-Time Specification for Java • Real-time embedded issues invoked need for RT Java specification. • PERC has been developing real-time Java API extensions since 1997, but still a need for organized structure and universal standard. • Java Community Process formed in 1998 to resolve some of the real-time issues and come to a standard. • Standard known as Real-Time Specification for Java (RTSJ), and was officially completed in Nov. 2001

16. RTSJ 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.

17. 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.

18. 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.

19. 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.

20. 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

21. Thread Scheduling and Dispatching • Programmatic assignment of parameters appropriate for the underlying scheduling mechanism in use. • Creation, management, admittance, and termination of real-time Java threads. • Threads are constructed as instances of class javax.realtime.RealtimeThread, which extends java.lang.Thread. • Flexibility in thread scheduling framework allows future specifications to build on the RTSJ.

22. Thread Scheduling (Cont.) • Base-scheduling mechanism is preemptive, priority-based FIFO. • At least 28 unique priority levels. • Threads waiting to acquire a resource must do so in execution eligibility order.

23. Memory Management • RTSJ introduces concept of memory area. • Area of memory used for the allocation of objects. • Some memory areas exist outside of the heap and place restrictions on what the system and garbage collector may do with objects allocated within. • Objects in some memory areas are never garbage collected. • Garbage collector must be capable of scanning these memory areas for references to any object within the heap to preserve the integrity of the heap.

24. 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.

25. Memory Class Hierarchy VTMemory Object HeapMemory LTMemory MemoryArea ScopedMemory ScopedPhysicalMemory ImmortalMemory ImmortalPhysicalMemory PhysicalMemoryFactory RawMemoryAcess RawMemoryFloatAcess Taken from Prof. Insup Lee, Univ. Penn.

26. Memory Management • Immortal Memory Area • One ImmortalMemory object per JVM. • Used for sharing between real-time threads. • No control in the program can ever leave the immortal memory. • Scoped Memory Area • Associated with one or more scopes. • Scopes may have more than one associated memory area.

27. Synchronization and Resource Sharing • Implementations of the current keyword “synchronized” include one or more algorithms that prevent or bound execution eligibility inversion among real-time Java threads that share the resource. • Priority inheritance provided by default, with optional ceiling emulation.

28. 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.

29. Asynch. Event Class Hierarchy Runnable (I) Object Schedulable (I) AsyncEvent AsyncEventHandler • AsyncEventHandler behaves like Thread. It has a run() method. • BoundAsynchronousHandler can be used for added timeliness by binding each handler to a dedicated thread. BoundAsyncEventHandler Taken from Prof. Insup Lee, Univ. Penn.

30. Asynchronous Event Handling • AsyncEvent is an object that is programmatically bound to an AsyncEventHandler. The AsyncEventHandler class implements Runnable, and the overridden run() method is executed when the AsyncEvent is triggered. • Handlers execute with the semantics of a real-time thread. • RTSJ does not require that the handlers be implemented as threads, only that they execute as if they were.

31. Asynchronous Event Handling import javax.realtime.*; public class HardwareEventExample extends AsyncEvent { private in interruptNum; // construct new HW Event for given interrupt public HardwareEventExample(int num) { interruptNum = num; } // bind handler to interrupt public void setHandler(AsyncEventHandler h) { super.setHandler(h); Hardware.bind(interruptNum,h); } } class HardwareEventHandler extends AsyncEventHandler { private int interruptCount = 0; // interrupt handler method public void handleAsyncEvent() { interruptCount++; // driver code follows } }

32. Asynchronous Transfer of Control • Change in environment needs immediate attention. • Abandon current execution and take appropriate action.

33. Asynchronous Transfer of Control • Methods that have throws clause, including AsynchronouslyInterruptedException (AIE) in their signature will have that exception raised by the JVM when the interrupt() method for their thread is called.

34. AIE (AsynchronouslyInterruptedException) Class Hierarchy Object Throwable Exception Interruptible (I) InterruptedException AsynchronouslyInterruptedException Parameter for AIE.doInterruptible() Timed Taken from Prof. Insup Lee, Univ. Penn.

35. Asynchronous Thread Termination • Asynchronous Event Handling and ATC provides ways to manage execution in a real-time environment asynchronously. • By implementing these two together, we can achieve asynchronous thread termination.

36. Physical Memory Access • RTSJ defines a class that allows byte-level access to physical memory. • Also a class that allows construction of Java objects at particular address locations in physical memory.

37. PERC and Embedded Java • PERC (Portable Executive for Reliable Control) – developed by NewMonics • Virtual Machine specifically for embedded systems • Implements language extensions specifically designed to handle real-time activities

38. PERC and OS Support • Available for wide variety of platforms • JDK 1.3 compatibility • VxWorks, VxSim, OSE, OSE Softkernel, Linux, and WinNT support • Will be interesting to see PERC’s future now that RTSJ has been created.

39. Java technologies from Sun • Architecture - contains libraries, JVM and SDK • Configuration - Virtual Machine and minimal set of API’s • Profile - adds more API’s to make a complete specification for a device

40. Architectures • J2EE (Enterprise Edition) • Used in Embedded Server Applications • J2SE (Standard Edition) • For writing Applets and other applications • J2ME (Micro Edition) • For Embedded Systems

41. J2ME Java Card Edition = Core Libraries + VM J2ME CDC Libraries J2ME CDLC Libraries Java Card API CVM KVM Java Card VM Personal Profile Profiles MIDP Profile GSM Profile Open Platform Profile J2ME and Java Card Hierarchy

42. Configurations • CDC (Connected Device Configuration) • For next generation devices (car navigations systems) • Coupled with CVM • CDLC (Connected Device Limited Configuration) • For smaller devices with limited memory (cell phones, PDA’s) • Coupled with KVM

43. Virtual Machines • Older JVM’s • Personal Java • Embedded Java • Java Card • Current JVM’s • CVM • KVM

44. Personal Java • pJava is a modified version of the standard Java virtual machine (version 1.1) • Uses a minimum of 8 MB RAM • Contains the full AWT implementation • Includes tools for building compressed ROM images of class files

45. Embedded Java • More of a licensing tool to let companies choose which features companies want for their devices. • Java Filter takes list of class dependencies and removes unused libraries. • Java Check reassures that the correct API’s are used.

46. Java Card • Specialized compiler and API’s for running Java on smart cards. • Examples of smart cards • Memory cards can only retrieve data. Phone cards are one example. • Cards with microprocessors and less than 8K memory. Mostly used for storing money and security purposes.

47. C Virtual Machine (CVM) • Uses Java 2 feature set • Built on Java 1.2 specifications • For devices that have at least 2 MB of memory and 16 or 32 bit processors

48. K Virtual Machine (KVM) • Runs on systems with as low as 160KB total memory • Object code is 50K – 80K • Can run on 16 bit processors clocked to as low as 25 MHz • Implemented in native code for performance

49. Profiles • MIDP (Mobile Information Device Profile) • Foundation Profile • PDAP (Personal Digital Assistant Profile) • Extends the CDLC to take advantage of PDA’s • Currently under development

50. Foundation Profile • Base profile that other profiles can build from • For devices with network connectivity and no GUI