Real-Time Java

1. Real-Time Java Angelo Corsaro corsaro@cse.wustl.edu Department of Computer Science Washington University One Brookings Drive Box 1045 St. Louis MO, 63130 USA

2. Outline • Introduction • Real-Time Java Basics • Generative Programming • Performances • Concluding Remarks

3. Most of the real-time embedded systems are currently developed in C, and increasingly also in C++ It is becoming increasingly difficult to find C/C++ programmers or to retain them State of the Art C++ While writing in C/C++ is more productive than assembly code, they are not the most productive or error-free programming languages C++ is a feature rich, complex language with a steep learning curve, which makes it hard to find and retain experienced real-time embedded developers who are trained to use it well Companies are starting to struggle with the maintenance costs pf C/C++ applications

4. Java is gaining wide acceptance in different application domains thanks to its: Safety Simplicity Productivity State of the Art It is becoming relatively easy to find well trained Java Programmers There is the diffused and increasing perception that Java is “Fun” and C/C++ is not Due to its productivity and maintainability, Java is becoming more and more appealing to the embedded and (soft) real-time market.

5. Conventional Java is unsuitable for developing real-time systems Java Limitations • The scheduling of Java threads is purposely under-specified (so to allow easy implementation of JVM on as many platform as possible) • The GC can preempt for unbounded amount of time Java Threads • Java provides coarse-grained control over memory allocation, and it does not provide access to raw memory • Java does not provide high resolution time, nor access to signals, e.g. POSIX Signals

6. Conventional Java is unsuitable for developing real-time systems Java Limitations • The scheduling of Java threads is purposely under-specified (so to allow easy implementation of JVM on as many platform as possible) • The GC can preempt for unbounded amount of time Java Threads • Java provides coarse-grained control over memory allocation, and it does not provide access to raw memory • Java does not provide high resolution time, nor access to signals, e.g. POSIX Signals

7. What’s the real problem in making Java Real-Time?

8. Garbage Collection Processors P2 P1 time Java and Garbage Collection • One of the main hurdle for making Java usable in Real-Time systems comes from its garbage collected nature • While developer like the facilities provided by the GC, they cannot afford the unpredictability that they introduce • At one extreme some Garbage Collectors (GC) work in a stop the world and collect fashion Recently, some Garbage Collection algorithms have been proposed that reasonably bound the delay experienced by the mutator, however these require either extra hardware, or double extra heap space or both

9. Java and Garbage Collection • The Expert Group that designed the Real-Time Specification for Java, was faced with the problem of providing automatic memory management which would be usable by real-time applications • Based on the state of the art of GC algorithms, the Expert Group decided to provide a safe way of circumventing the GC, while maintaining automatic memory management • To make the problem more challenging, one of the requirements was that no extension to the language syntax was allowed • As described next, the Expert Group based its solution on Memory Regions

10. Road Map Introduction Real-Time Java Basics

11. The Real-Time Specification for Java (RTSJ) extends Java in the following areas: New memory management models that can be used in lieu of garbage collection Access to physical memory Stronger semantics on thread and their scheduling Asynchronous Event handling mechanism Scheduling Service Timers and Higher time resolution Real-Time Java

12. The Real-Time Specification for Java (RTSJ) extends Java in the following areas: New memory management models that can be used in lieu of garbage collection Access to physical memory Stronger semantics on thread and their scheduling Asynchronous Event handling mechanism Scheduling Service Timers and Higher time resolution RTSJ Real-Time Java

13. The Real-Time Specification for Java (RTSJ) extends Java in the following areas: New memory management models that can be used in lieu of garbage collection Access to physical memory Stronger semantics on thread and their scheduling Asynchronous Event handling mechanism Scheduling Service Timers and Higher time resolution The RTSJ does not extend syntactically the Java language, but simply strengthen the semantics of certain Java features, and adds libraries classes RTSJ Real-Time Java

14. These memory areas are characterized by Lifetime of the object allocated within the memory area, and The allocation time Objects allocated in the ImmortalMemory are guaranteed to exist as long as the JVM Objects allocated in Scoped Memories are not garbage collected; instead a reference counted mechanism is used to detect when all the objects allocated in the scope can be reclaimed RTSJ Memory Model RTSJ extends the Java memory model by providing memory areas other than the Heap The model used by the RTSJ is inspired to Memory Regions

15. The rules that govern the access to the scoped memory are the following: Only Real-Time Threads can allocate memory in a region different than the heap A new allocation context or scope is entered by calling the MemoryArea.enter() method or by starting a new real-time thread whose constructor was given a reference to a scoped memory instance Once a scoped memory is entered all the subsequent use of the newoperator will allocate memory from the current scope When the scope is exited by returning from the MemoryArea.enter() all subsequent use of the newoperator will allocate memory from the enclosing scope A Real-Time Thread thread is associated with a scope stack containing all the memory areas that the thread has entered but not yet exited Scoped Memory Access Rules

16. Scoped Memory Behaviour Rules • The rules that govern the scoped memory behaviour are the following: • Each instance of the class ScopedMemory has to maintain a reference count of the number of threads active in that instance • When the reference count of the ScopedMemory drops to zero, all the objects in the area are considered unreachable and candidates for reclamation • Each ScopedMemory has at most one parent defined as follows. For a ScopedMemory pushed on a scope stack its parent is the first ScopedMemory below in on the stack if it exists the primordial scope otherwise. A scope that is not pushed on any stack ha no parent

17. Single Parent Rule • The RTSJ defines the single parent rule so to make sure that a thread can only enter scopes that will live at least as much as the outer scopes The single parent rule is enforced at the point in which a real-time thread tries to enter a scoped memory. Traditional algorithms have O(n) time complexities, Corsaro and Cytron have recently shown how to perform this test in O(1)

18. The RTSJ imposes a set of rules that govern the validity of references across memory areas: A reference to an object allocated in a ScopedMemory cannot be allocated in the Java heap or in the Immortal memory A reference to an object allocated in a ScopedMemorym can be stored in an object allocated in a ScopedMemoryp only if p is a descendant scope of m Memory reference checks are performed potentially at each store so the algorithm used to performs the checks should be predictable and efficient Memory Reference Rules

19. Scoped Memory: An Example import javax.realtime.* public class SMSample { public static void main(String[] args) { Runnable logic = new Runnable() { public void run() { MemoryArea ma2 = new LTMemory(128 * 1024, 128 * 1024); Runnable nestedLogic = new Runnable(){ publicvoid run() {A a = new A();} }; m2.enter(nestedLogic); } }; MemoryArea ma1 = new LTMemory(512 * 1024, 512 s* 1024); RealtimeThread rtThread = new RealtimeThread(null, null, null, ma1, null, logic); rtThread.start() } }

20. Every compliant JVM has to perform memory reference checks in order to maintain Java safety, avoiding memory leaks and dangling pointers Some memory reference checking can be eliminated at compile time by pointer escape analysis Undecidability issues imply that some, perhaps many, checks still need to be performed at run-time Poor implementation of these checks could adversely impact performances and predictability Solution available on literature were not suitable for many reasons, mostly because they would lead to problem in code timing analysis Memory Reference Checking

21. Recently, Corsaro and Cytron have proposed an algorithm based on type theory for performing this test in O(1), as opposed to the O(n) solution available in literature Memory Reference Checking

22. The RTSJ extends the Java threading model with two new types of thread RealtimeThread NoHeapRealtimeThread NoHeapRealtimeThread cannot refer to any object allocated on the heap. This make it possible for this kind of thread to preempt the GC Real-Time Threads provide facilities for periodic computations For a Real-Time Thread it is possible to specify Release Parameters Scheduling Parameteres Memory Parameters Thread execution is managed by the associated scheduler Real-Time Threads

23. The AsyncEventHandler class, does not have a thread permanently bound to it—nor is it guaranteed that there will be a separate thread for each AsyncEventHandler The BoundAsyncEventHandler class has a real-time thread associated with it permanently The RTSJ defines mechanisms to bind the execution of program logic to the occurrence of internal and/or external events The RTSJ provides a way to associate an asynchronous event handler to some application-specific or external events. Event Handling

24. The RTSJ provides a policy independent scheduling framework Only Schedulable entities are considered for scheduling and feasibility purpose The responsibility of the scheduling framework are: Schedule Schedulable Entities Performing Feasibility Analysis Schedule appropriate handlers in case of error Different schedulers can potentially be used within a running applications The default scheduler is a Priority-Preemptive scheduler that distinguish 28 different priorities Schedulable entities are characterized by: Scheduling Parameteres Release Parameters Memory Parameters Erroneous situations are handled by event handler associated with Release Parameters: Overrun Handler Deadline Miss Handler Scheduling

25. Real-time embedded systems often use timers to perform certain actions at a given time in the future, as well as at periodic future intervals The RTSJ provides two types of Timers OneShotTimer, which generates an event at the expiration of its associated time interval, and PeriodicTimer, which generates events periodically Along with timers the RTSJ provides a set of classes to represent and manipulate high resolution time, and specifically Absolute Time Relative Time Rational Time Time and Timers

26. Outline • Introduction • Real-Time Java Basics • Generative Programming

27. While the RTSJ represents an ambitious step toward improving the state of the art in embedded and real-time system development, there are a number of open issues The RTSJ was designed with generality in mind, while this is a laudable goal, generality is often at odds with the resource constraints of embedded systems Does One Size Fits All?

28. While the RTSJ represents an ambitious step toward improving the state of the art in embedded and real-time system development, there are a number of open issues The RTSJ was designed with generality in mind, while this is a laudable goal, generality is often at odds with the resource constraints of embedded systems Providing developers with an overly general API can actually increase the learning curve and introduce accidental complexity in the API itself For example, the scheduling API in RTSJ was designed to match any scheduling algorithm, including RMS, EDF, LLF, RED, MUF, etc. While this generality covers a broad range of alternatives it may be overly complicated for an application that simply needs a priority preemptive scheduler Does One Size Fits All?

29. Can we do any better then this?

30. Can we provide the needed flexibility and extensibility, without putting undue burden on developers?

31. The Answer is…

32. Generative Programming • Generative Programming brings the benefit of Economies of Scope to software engineering, where less time and effort are needed to produce a greater variety of products Generative Programming aims at building generative models for families of systems and generate concrete systems from these models

33. One System Generative Programming • Generative Programming brings the benefit of Economies of Scope to software engineering, where less time and effort are needed to produce a greater variety of products Generative Programming aims at building generative models for families of systems and generate concrete systems from these models Classical Approach Design Space

34. A Family of Systems One System Generative Programming • Generative Programming brings the benefit of Economies of Scope to software engineering, where less time and effort are needed to produce a greater variety of products Generative Programming aims at building generative models for families of systems and generate concrete systems from these models Classical Approach Generative Programming Approach Design Space Design Space

35. Generative Programming (GP) makes it possible to develop Software Systems that are amenable to customization of behavior and protocols (e.g., APIs), via automatic code generation and composition Using a GP approach, the development of middleware, such as RTSJ or Real-time CORBA, need not lead to a single implementation. Instead, it can provide a set of components and configuration knowledge that can be used to generated a specific implementation based on user-defined specifications Generative Programming If we consider the RTSJ scheduling API example, for instance, application developers that need a simple priority preemptive scheduler could use generative programming to specify this as a requirement. The outcome of the generation process would then be a Realtime Java platform that exposed only the API needed for a priority-based scheduler and whose implementation was also optimized for priority-based schedulers.

36. jRate:The Chameleonic RTSJ • jRate’s is an extension of the GCJ runtime system that provides a subset of the RTSJ features such as: • Realtime Threads • Scoped Memory • Asynchrony • Timers • jRate’s goals: • Use a Generative Programming approach to provide a “Chameleonic” Real-Time Java, which can adapt to its target environment in term of API and functionalities • AOP techniques will be used to produce an untangled, and “pick what you need” RTSJ implementation • AspectJ, C++ Templates, Python, will be used to do AOP in the Java and C++ portion of jRate respectively • Provide higher level programming model to developers • Provide advanced scheduling services

37. Real-Time Java Specific Concepts and Features A Real-Time Java Specification Configuration Knowledge Generated Real-Time Java Platform Generative Real-Time Java

38. Outline • Introduction • Real-Time Java Basics • Generative Programming • Performances

39. RTJPerf & Tested Platforms • RTJPerf is a benchmarking suite for RTSJ compliant platforms that focuses on Time-efficiency performance indexes. • RTJPerf provides a series of tests based on synthetic workload • RTJPerf currently covers the following RTSJ areas: • Memory • Threading • Asynchrony • Timers • RTSJ Reference Implementation, developed by TimeSys • Provides all the mandatory RTSJ features jRate, an Open Source RTSJ-based extension of the GCJ runtime system Currently provide only a subset of the mandatory RTSJ features All test were run on a Pentium III 766MHz running TimeSys Linux/GPL

40. Allocation Time Test Test Parameters: • 1,000 Sample for each chunk size were collected Objective: • Determine the allocation time for different kind of ScopedMemory provided by the RTSJ Technique: • Allocate vector of characters for different sizes ranging from 32 to 16K bytes Tested Platform: • RTSJ RI • jRate

41. Test Statistics 1/3

42. Test Statistics 2/3

43. Test Statistics 3/3 • As the size of the chunk allocated increases the speedup of jRate’s CTMemory over the RI LTMemory can be as much as 95. • The CTMemory speedup over the LTMemory grows linearly with the size of the chunk being allocated

44. Dispatch Delay Latency Tested Platforms: • RTSJ RI, jRate Objective: • Measure the time elapsed from when an event is fired up to when its associated handler is invoked Technique: • Associate an handler with and AsynchEvent, fire repeatedly in lock step mode the event. Measure the time elapsed between the firing of the event and the handler activation Test Parameters: • 2,000 samples of the dispatch delay time were collected

45. Sample Trace • jRate’s AsynchEventHandler and BoundAsynchEventHandler have similar performances • The sample trace shows a very predictable dispatch delay for jRate • RI’s BoundAsynchEventHandler provide a quite good dispatch delay latency, but is less predictable • RI’s AsynchEventHandler expose a strange behaviour (caused perhaps by a resource leaks associated with thread management) • The Dispatch Latency grows linearly with the number of event fired

46. Test Statistics • jRate’s handlers have worst cases performances very close to the average and 99% case • jRate’s handler behavior quite predictable, as the low std. dev. indicates • RI’s BoundAsynchEventHandler has a 99% behaviour that is very close to the average case while the worst case behaviour is a little bit off. • RI’s AsynchEventHandler exposes an odd behaviour (as shown previously), so its data is not very representative

47. Concluding Remarks • Real-Time Java is a quite intriguing technology, but there is still quite a bit of R&D to be done in order to make it sound • Many aero-spatial companies and federal research institution have placed big bets on Real-Time Java, some of these are: • BOEING • NASA • Air Force Research Laboratory • DARPA • Generative Programming techniques are an interesting topic, and more research is needed in this area in order to understand: • GP Pattern and Pattern Languages • GP Methodologies • GP Techniques and Tools • jRate provide a vast playground for experimenting with Real-Time Java features as well as with GP • GP provides a good balance between flexibility and performance/efficiency

48. References • jRate Web: • http://tao.doc.wustl.edu/~corsaro/jRate • Papers on jRate: • http://tao.doc.wustl.edu/~corsaro/papers.html • Real-Time Java Expert Group • http://www.rtj.org • Reference Implementation • http://www.timesys.com • Mailing List • rtj-discuss@nist.gov • Related Work • GCJ (http://gcc.gnu.org) • FLEX Compiler, MIT • OVM Virtual Machine, Purdue University • JamaicaVM, European Space Agency • PERC, NewMonics