1 / 38

A Little Bit of Real-Time Java

A Little Bit of Real-Time Java. Nels Beckman SSSG November 7 th , 2005. Introduction. Design choices, trade-offs and motivations in the Real-Time Specification for Java Effects of these choices Possible high-level research directions. Outline. Introduction RTSJ Background

pilialoha
Télécharger la présentation

A Little Bit of Real-Time Java

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. A Little Bit of Real-Time Java Nels Beckman SSSG November 7th, 2005

  2. Introduction • Design choices, trade-offs and motivations in the Real-Time Specification for Java • Effects of these choices • Possible high-level research directions Nels Beckman, SSSG

  3. Outline • Introduction • RTSJ Background • Seven Enhanced Areas • New Memory Model • Comments on RTSJ • Conclusion Nels Beckman, SSSG

  4. RTSJ Background Briefly: What is Real-Time? • “A real-time system is one that has performance deadlines on its computations and actions n” • Real-time software is • Event-driven, Time-Driven, or both • Often embedded • Often safety-critical • Example: • Flow-Rate Control System3 Nels Beckman, SSSG

  5. RTSJ Background What is the RTSJ? • Standard Java is not appropriate for RT • It provides additions to Java, so it can be used in the development of real-time systems • Specifically • Extensions to JVM Specification • Creation of real-time API Nels Beckman, SSSG

  6. RTSJ Background Why Real-Time Java? • Java = Slow? • Real-Time = Fast? • Real-time applications typically are a mixture of real-time and non real-time threads1 • So what about the “rest” of the code in a RT application? Nels Beckman, SSSG

  7. RTSJ Background History of the RTSJ • Core requirements originate from NIST workshop • The first Java Specification Request in the Java Community Process (1999) • Proposed by IBM • The Real-Time Java Experts Group was chartered with leading its creation • Members of Note • Greg Bollella • Ben Brosgol • James Gosling Nels Beckman, SSSG

  8. Applicability to Particular Java Environments Backward Compatibility Write once, Run Anywhere Current Practice/Advanced Features Predictable Execution No syntactic extension Allow Variation in Implementation Decisions RTSJ Background RTJEG’s Guiding Principles2 Nels Beckman, SSSG

  9. Outline • Introduction • RTSJ Background • Seven Enhanced Areas • New Memory Model • Comments on RTSJ • Conclusion Nels Beckman, SSSG

  10. 7 Enhanced Areas 1. Thread Scheduling & Dispatching • Original Java Spec: “…threads with higher priority are generally executed in preference to threads with lower priority…” • RTSJ • Requires at least a fixed priority, preemptive scheduler. • Defines classes for execution eligibility and schedule feasibility. Nels Beckman, SSSG

  11. 7 Enhanced Areas 2. Synchronization • RTSJ adds: • Priority queuing on synchronized blocks • Required priority inversion avoidance • Wait free queues Nels Beckman, SSSG

  12. 7 Enhanced Areas 3. Asynchronous Event Handling • Real-time applications typically must respond to events in the real world and in other parts of the application • RTSJ Adds: • Asynchronous events • Asynchronous event handlers • Handlers are runnable, and thus are associated with deadline information, etc. • Events include periodic and one shot timers Nels Beckman, SSSG

  13. 7 Enhanced Areas 4. Asynch. Transfer of Control • Occasionally necessary to transfer control immediately and permanently • RTSJ adds ATC • Code declares itself interruptible (think ‘throws’). • Asynchronous events can enact a transfer of control to a predetermined point. Nels Beckman, SSSG

  14. 7 Enhanced Areas 5. Asynch. Thread Termination • A more specific case of asynchronous transfer of control • Java • thread.stop(),thread.destroy() • Deprecated, can lead to deadlock • RTSJ • thread.interrupt() • Thread can catch interruption and clean up Nels Beckman, SSSG

  15. 7 Enhanced Areas 6. Physical Memory Access • RTSJ Adds: • Direct access to physical memory • You specify the address range • Individual bytes, ints, longs, etc. can be accessed Nels Beckman, SSSG

  16. 7 Enhanced Areas 7. Memory Management • Java has garbage collection • Garbage collection is certainly easy to use • But is it real-time appropriate? • State-of-the-art in real-time garbage collection4 • ~50% cpu overhead • 1.5X memory overhead. Nels Beckman, SSSG

  17. Memory Management So No Heap? Now What? • RTSJ has multiple thread types • Thread • RealtimeThread • NoHeapRealtimeThread Nels Beckman, SSSG

  18. Memory Management Three Types of Memory • Heap memory • Standard Java Heap • Immortal memory • Immortal memory, exists for the life of the application • Scoped Memory • A way to reclaim memory without a garbage collector Nels Beckman, SSSG

  19. Memory Management Scoped Memory • Scopes have fixed lifetimes • Lifetime starts here: • scopedMemArea.enter() { … } • Lifetime ends: Nels Beckman, SSSG

  20. Memory Management Scoped Memory • All calls to new inside a scope, create an object inside of that scope • When the scope’s lifetime ends, all objects within are destroyed Nels Beckman, SSSG

  21. Memory Management Scope Nesting • Scopes can be nested • scopedMemArea.enter() { ... anotherScope.enter() { } ... } Nels Beckman, SSSG

  22. Memory Management Memory Safety • Must ensure • No dangling pointers • Objects can’t refer to shorter lived objects • An RTSJ must ensure this with run-time checks heap immortal parent child Nels Beckman, SSSG

  23. Memory Management Common Scoped Memory Patterns • Scoped Loops • Used when temporary information created at each iteration of a loop • eg.) void mainLoop() { while(true) { ... }} Nels Beckman, SSSG

  24. Memory Management Common Scoped Memory Patterns • Scoped Loops • Used when temporary information created at each iteration of a loop • Now: Class Runner implements Runnable { void run() { ... }} void runLoop() { memory = new LTMemory( size,max ); myRunner = new Runner(); while(true) memory.enter( myRunner );} Nels Beckman, SSSG

  25. Memory Management Common Scoped Memory Patterns • Scoped Methods • Similar to scoped loops • Body of method runs in memory scope • Caveat: • State must be saved in a parent scope • Must take explicit care to do this Nels Beckman, SSSG

  26. Memory Management A Programmer’s Nightmare? • Programming mistakes lead to run-time errors • StateObject state; void run() { state = new StateObject(); Runner r =new Runner(state); nestedScope.enter(r); //Here is ‘state’ in my scope? //Is it in sub scope? } Nels Beckman, SSSG

  27. Memory Management What’s the Problem Here? • The particular scope in which a given object resides in is implicit • The nesting relationship of scopes is implicit • Nesting relationship can change at run-time • The RTSJ has some capability here, but still requires run-time comparisons Nels Beckman, SSSG

  28. Memory Management Some Proposed Techniques • Scoped Types for Real-Time Java, Vitek et. al. • Ownership-types for Safe Region-Based Memory Management in Real-Time Java, Boypati, et al. • Cyclone: A Safe Dialect of C • All proposed techniques integrate memory location into the type system. Nels Beckman, SSSG

  29. Memory Management Sharing Data Between Threads • More Funny Behavior • Portals provide placeholder for shared data • But scopes are deleted when no threads occupy it! • This can make sharing data hard! Nels Beckman, SSSG

  30. Memory Management Sharing Data Between Threads finalize() Nels Beckman, SSSG

  31. Memory Management Sharing Data Between Threads • So we get hacks! • The Wedge-Thread pattern • Sleeps a thread inside the memory scope in order to keep it alive • Then receiver thread wakes sleeping thread up again • This is Backhanded Memory Management! Nels Beckman, SSSG

  32. RTSJ Commentary Comments on the RTSJ • First: Designing frameworks and extensions is hard • External constraints: • eg.) Syntax should stay the same to preserve tool compatibility • Finding balance between users’ previous experience, and what the new domain mandates • eg.) We would like to use garbage collection, but performance is unacceptable Nels Beckman, SSSG

  33. RTSJ Commentary Comments on the RTSJ • Tendencies are hard to break? • Java tends to push errors towards run-time discovery • But this philosophy may be counter to Real-Time • eg.) When my real-time app is running, what do I do with a MemoryAccessError? What about a ScopeCycleException? • Designers of real-time applications don’t like to be surprised! Nels Beckman, SSSG

  34. RTSJ Commentary Comments on the RTSJ • Would real-time developers use the RTSJ? • I say it depends on the task • In safety critical systems, for the most part, memory is not dynamically allocated. • But realistically, RTSJ seems targeted at soft real-time, or at least non critical. Nels Beckman, SSSG

  35. RTSJ Commentary Proposed Research Directions • Soft real-time is an interesting problem space • Can currently ‘interactive’ software, be given some real-time guarantees? • Appliances, media decoders, etc. • Can we make it cheaper to do? • Hopefully, type systems and annotations may provide the answer! Nels Beckman, SSSG

  36. RTSJ Commentary Proposed Research Directions • Currently, reading up on type systems that help us to bound resource usage Nels Beckman, SSSG

  37. Conclusion: • Thanks for your attention • I hoped you learned something about Real-Time/RTSJ! Nels Beckman, SSSG

  38. References • Bollella, G., Canham, T., Carson, V., Champlin, V., Dvorak, D., Giovannoni, B., Indictor, M., Meyer, K., Murray, A., and Reinholtz, K. 2003. Programming with non-heap memory in the real time specification for Java. In Companion of the 18th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (Anaheim, CA, USA, October 26 - 30, 2003). OOPSLA '03. ACM Press, New York, NY. • Bollella, G.; Gosling, J. The real-time specification for JavaComputer, Vol.33, Iss.6, Jun 2000 Pages:47-54 • Douglass, B. P. 1999 Doing hard time: developing real-time systems with UML, objects, frameworks, and patterns. Addison-Wesley Longman Publishing Co., Inc. • Tian Zhao, James Noble, Jan Vitek. "Scoped Types for Real-Time Java," rtss, pp. 241-251,  25th IEEE International Real-Time Systems Symposium (RTSS'04),  2004. • Pizlo F, Fox JM, Holmes D, Vitek J. “Real-Time Java Scoped Memory: Design Patterns and Semantics.” Nels Beckman, SSSG

More Related