1 / 39

Is Java Ready For Real-Time Embedded Systems?

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

brook
Download Presentation

Is Java Ready For Real-Time Embedded Systems?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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. 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. 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. _213_javac _222_mpegaudio _227_mtrt _228_jack JVM98 SPEC Benchmark 1/3 • The JVM98 SPEC Benchmark is composed by the following applications • _200_check • _201_compress • _202_jess • _209_db General Performance

  6. JVM98 SPEC Benchmark General Performance J9 JVM98 Results JView JVM98 Results Javac JVM98 Results

  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 Audio Sample Filter Filtered Audio Sample x(k) y(k)

  8. Filter Performance General Performance

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

  10. Hanoi Tower General Performance

  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. Garbage Collection Performance 1/5 General Performance

  13. Garbage Collection Performance 2/5 General Performance

  14. Garbage Collection Performance 3/5 General Performance

  15. Garbage Collection Performance 4/5 General Performance

  16. Garbage Collection Performance 5/5 General Performance

  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. 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. PreemptTest Results 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 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.

  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. 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. PriInvertTest Results RT Performance 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.

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

  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. 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. 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.). RT Performance Result: Quite good - jitter between runs of handler within RTOS timer resolution.

  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.). RT Performance Result: Not bad - some jitter (+/- 1.1 msec) between runs, but lower priority threads do seem to affect jitter.

  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.). RT Performance Result: Bad - the periodic events never get to the handler, even though the handler has higher priority than the other RealtimeThread.

  31. EventJitterTest Analysis • Apparent AsyncEventHandler mechanization • At least for PeriodicTimer driven AsyncEvents Handler thread Java pri=30 QNX pri=15r PeriodicTimer’s fire() method called Handler thread Java pri=30 QNX pri=15r Handler thread Java pri=30 QNX pri=15r Handler thread Java pri=30 QNX pri=15r “Spawner” thread QNX pri=8r RT Performance 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.

  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 RT Performance For priority 9, jitter is off the scale due to contention with “spawner”. (previous slide) Other threads are processor-keeping and run time-sliced at the same priority. Dip at exactly 50 threads - repeatable

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

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

  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. EventTimingTest Results High priority (30) AsynchEventHandler with 50 other processor-keeping RT threads of priority 1. 100 samples taken. RT Performance Result plotted.

  37. EventTimingTest Analysis (cont) High priority (30) AsynchEventHandler with various number of other processor-keeping RT threads. 100 samples taken for each point. • 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 RT Performance About 2 msec average latency for this condition below 300 other threads

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

More Related