1. Is Java Ready For Real-Time Embedded Systems? Angelo Corsaro corsaro@cs.wustl.edu DOC Group Washington University St. Louis, USA David Sharp, Jim Urnes, Jr. david.sharp@boeing.com, james.m.urnes-jr @boeing.com Boeing St. Louis USA

2. 2 Table of Contents  Real Time Java  General Performance  JVM98 SPEC Benchmark  Filtering  Hanoi Tower  Garbage Collection  RT Performance  Thread Preemption Behavior  Priority Inversion Avoidance  Jitter in Periodic Event Handling  Timing in Periodic Event Handling  Concluding Remarks

3. 3 What’s Going On?  During Y2K two specification for extending Java with Real-Time capabilities have appeared, specifically  RTSJ from the Real Time Java Expert Group (headed by Greg Bollella)  J-Consortium Specification for Real Time Java  Sun supports the RTSJ, and the market seems to head in the same direction  Ajile had already implemented a subset of the spec on HW already last August  IBM provided us with the first “implementation” of a RTJVM  TimeSys has been selected by Sun to implement the reference JVM that will implement the RTSJ specification Real Time Java

4. 4 What is RTJava  Real Time Java is an extension of the Java platform to allow the development of Real Time Application  The RTJava specification enhance 7 areas  Thread Scheduling and Dispatching  Memory Management  Synchronization and Resource Sharing  Asynchronous Event Handling  Asynchronous Transfer of Control  Asynchronous Thread Termination  Physical Memory Access Real Time Java

5. 5 JVM98 SPEC Benchmark 1/3  _200_check  _201_compress  _202_jess  _209_db  _213_javac  _222_mpegaudio  _227_mtrt  _228_jack General Performance  The JVM98 SPEC Benchmark is composed by the following applications

6. 6 JVM98 SPEC Benchmark General Performance J9 JVM98 ResultsJView JVM98 ResultsJavac JVM98 Results

7. 7 Application Description  Finite Impulse Response (FIR) Filter with 21 tap  The filter implement a noise attenuation on audio samples  Filters coefficient and sample data are double General Performance Filter Audio SampleFiltered Audio Sample x(k)y(k)

8. 8 Filter Performance General Performance

9. 9 Application Description  Java implementation of the Algorithm that solves the famous Hanoi Tower game General Performance

10. 10 Hanoi Tower General Performance

11. 11 Application Description  Build a full binary tree of height H  Each node of the binary tree allocates a slot of memory of B bytes  Analyze the following case  Once the tree is build, remove the reference from the root, and force the garbage collection  Create and release while building the tree to investigate if the JVM have some sort of incremental GC General Performance

12. 12 Garbage Collection Performance 1/5 General Performance

13. 13 General Performance Garbage Collection Performance 2/5

14. 14 Garbage Collection Performance 3/5 General Performance

15. 15 Garbage Collection Performance 4/5 General Performance

16. 16 General Performance Garbage Collection Performance 5/5

17. 17 Test Cases  Real-time determinism test cases  RealtimeThread preemption handling (PreemptTest)  Priority inversion avoidance (PriInvertTest)  Dispatching of AsyncEvents (EventDispatchTest2)  Jitter in periodic event handling (EventJitterTest)  Timing of periodic event handling (EventTimingTest) RT Performance

18. 18 PreemptTest Scenario  Purpose:  Measure whether priority preemption occurs correctly for multiple RealtimeThreads of different priorities  Method:  Stagger the start of fixed-duration, processor-holding RealtimeThreads of increasing or decreasing priority. Using timestamp logging, see when threads enter and exit in relation to each other RT Performance

19. 19 PreemptTest Results Result: Thread 1 worked correctly, it kept the processor until it was done. But threads 2, 3, and 4, all started immediately upon thread 1 finishing. They ran simultaneously and when complete, threads 5, 6, and 7 all started and ran simultaneously. Thread preemption did not work correctly. Starting at priority 7, start the treads every 2 seconds in decreasing priority order. Threads try to keep the processor for 7 seconds. This works! Problem! Enter and leave in blocks of 3 RT Performance

20. 20 PreemptTest Analysis  Problem  The IBM j9 groups multiple Java thread levels to a single underlying RTOS thread level  RTSJ Requires at least 28 unique priority levels  Suggestion  Allow underlying RTOS threads to be FIFO as well as Round Robin RT Performance

21. 21 PriInvertTest Scenario  Purpose:  Measure whether priority inversion is properly avoided.  Method:  A low priority thread obtains a lock on a synchronized method, a medium thread preempts the low, and a high priority thread preempts the medium and attempts to obtain a lock on the same synch’d method. Log entry and exit times for the threads and synchronized method. RT Performance

22. 22 PriInvertTest Results Result: The low priority thread did NOT get elevated to high priority to finish the shared method. Therefore, the medium priority thread got to finish before the high priority thread. Priority inversion occurred. RT Performance

23. 23 PriInvertTest Analysis  Problem  Priority Inheritance does not currently work  RTSJ specifies Priority Inheritance as the default priority inversion avoidance method for synchronized blocks RT Performance

24. 24 EventDispatchTest Scenario  Purpose:  Measure the execution order for multiple AsyncEventHandlers of different priority when an AsyncEvent fires for which they are all registered.  Method:  Set up three AsyncEventHandlers of different priority, all registered to the same AsyncEvent. Issue the event and have the handlers log timestamps on entry and exit. RT Performance

25. 25 EventDispatchTest Results Result: This is correct. The highest priority handler runs first, then next highest, and then lowest. In this tests the Java priorities are such that the resulting QNX priorities are different. Result: This is incorrect. The handlers don’t start in priority order and preempt each other. In this tests the Java priorities are such that the resulting QNX priorites are the same. RT Performance

26. 26 EventDispatchTest Analysis  Problem  The OTI j9 groups multiple Java thread levels to a single underlying RTOS thread level  RTSJ requires 28 unique priority levels RT Performance

27. 27 EventJitterTest Scenario  Purpose:  Measure the amount of time variation between runs of a PeriodicTimer driven AsyncEventHandler with various other activity occurring.  Method:  Setup a PeriodicTimer object to fire an AsyncEventHandler at a fixed rate, while other lower priority, processor-keeping RealtimeThreads run. Log a timestamp each time the handler runs. After the run, import the data to Excel for analysis. RT Performance

28. 28 EventJitterTest Results In this 1 second test, our AsyncEventHandler runs at java priority 30. Another RealtimeThread runs at java priority 6. PeriodicTimer event fires every 50 msecs (20 Hz.). Result: Quite good - jitter between runs of handler within RTOS timer resolution. RT Performance

29. 29 EventJitterTest Results (cont) In this 1 second test, our AsyncEventHandler runs at java priority 30. 200 other RealtimeThreads runs at java priority 6. PeriodicTimer event fires every 50 msecs (20 Hz.). Result: Not bad - some jitter (+/- 1.1 msec) between runs, but lower priority threads do seem to affect jitter. RT Performance

30. 30 EventJitterTest Results (cont) In this 1 second test, our AsyncEventHandler runs at java priority 30. Another RealtimeThread runs at java priority 10. PeriodicTimer event fires every 50 msecs (20 Hz.). Result: Bad - the periodic events never get to the handler, even though the handler has higher priority than the other RealtimeThread. RT Performance

31. 31 Handler thread Java pri=30 QNX pri=15r EventJitterTest Analysis  Apparent AsyncEventHandler mechanization  At least for PeriodicTimer driven AsyncEvents “Spawner” thread QNX pri=8r Handler thread Java pri=30 QNX pri=15r Handler thread Java pri=30 QNX pri=15r PeriodicTimer’s fire() method called Handler thread Java pri=30 QNX pri=15r handler thread of desired priority spawned for each firing Another thread Java pri = 10 QNX pri = 9r Problem! If this thread is using the processor, the “Spawner” thread will not get the opportunity to spawn the handler thread. Priority inversion occurs. RT Performance

32. 32 EventJitterTest Analysis (cont)  Results for AsyncEventHandler with priority 30 (highest)  All data points are 100 second runs at 20 Hz (50 msecs)  3 sets of data analyzed with other RealtimeThreads run at priority 1, 6, and 9 respectively Other threads are processor-keeping and run time-sliced at the same priority. Dip at exactly 50 threads - repeatable For priority 9, jitter is off the scale due to contention with “spawner”. (previous slide) RT Performance

33. 33 EventJitterTest Analysis (cont) Absolute period measurements For other numbers of RT threads, some jitter outside +/- 1 msec occurs. 0 or50 other RT threads results in jitter values around +/- 1 msec, probably due to RTOS timer resolution

34. 34 EventJitterTest Analysis (cont) –Standard deviation and Mean Std Dev trend increases with number of other RT threads Degradation above 250 threads, perhaps hitting processor throughput limit RT Performance

35. 35 EventTimingTest Scenario  Purpose:  Measure the time it takes for an AsyncEvent to get from firing to its handler. Vary priority and other processor activity.  Method:  Set up an AsyncEvent and associated AsyncEvent handler at specified priority. Over a number of iterations, log the timestamp before firing and upon entry into the handler. Run variable number of other processor-keeping RealtimeThreads. Import results to Excel for analysis. RT Performance

36. 36 EventTimingTest Results Result plotted. High priority (30) AsynchEventHandler with 50 other processor-keeping RT threads of priority 1. 100 samples taken. RT Performance

37. 37 EventTimingTest Analysis (cont)  Still under investigation  If handler priority lowered to 15, the average latency improves to about 0.6 msec –Does not exhibit the “spawner” thread priority inversion of the PeriodicTimer driven AsyncEventHandler High priority (30) AsynchEventHandler with various number of other processor-keeping RT threads. 100 samples taken for each point. About 2 msec average latency for this condition below 300 other threads RT Performance

38. 38 Summary Of Experimental Results  Java thread priority preemption must be maintained for each of the 28 required thread levels.  AsyncEventHandler threads driven by PeriodicTimers must not be prevented from running by lower priority threads.  Priority inheritance should work by default.  Programmer needs better control of Java thread to underlying RTOS mapping. RT Performance

39. 39 Concluding Remarks  JIT provide acceptable performance to Java, and improvement in this area will close the performance gap with C++ (which is already within a factor 2)  J9 RT-Java extension are still very minimal, and cannot be considered yet for industrial strength development  The J9 RT-Java extensions suffer of some major problem, mainly  Priority Mapping  Priority Inversion Effect induced by the “Spawner”  This investigation has provided us with Test-Bed that will make easier to evaluate the “performance” of a RT- JVM once mature (complete) implementation will start to appear