A Little Bit of Real-Time Java Nels Beckman SSSG November 7 th, 2005

11/7/05Nels Beckman, SSSG2 Introduction 1.Design choices, trade-offs and motivations in the Real-Time Specification for Java 2.Effects of these choices 3.Possible high-level research directions

11/7/05Nels Beckman, SSSG3 Outline Introduction RTSJ Background Seven Enhanced Areas New Memory Model Comments on RTSJ Conclusion

11/7/05Nels Beckman, SSSG4 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 System 3 RTSJ Background

11/7/05Nels Beckman, SSSG5 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 RTSJ Background

11/7/05Nels Beckman, SSSG6 Why Real-Time Java? Java = Slow? Real-Time = Fast? Real-time applications typically are a mixture of real-time and non real-time threads 1 –So what about the “rest” of the code in a RT application? RTSJ Background

11/7/05Nels Beckman, SSSG7 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 RTSJ Background

11/7/05Nels Beckman, SSSG8 RTJEG’s Guiding Principles 2 1.Applicability to Particular Java Environments 2.Backward Compatibility 3.Write once, Run Anywhere 4.Current Practice/Advanced Features 5.Predictable Execution 6.No syntactic extension 7.Allow Variation in Implementation Decisions RTSJ Background

11/7/05Nels Beckman, SSSG9 Outline Introduction RTSJ Background Seven Enhanced Areas New Memory Model Comments on RTSJ Conclusion

11/7/05Nels Beckman, SSSG10 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. 7 Enhanced Areas

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

11/7/05Nels Beckman, SSSG12 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 7 Enhanced Areas

11/7/05Nels Beckman, SSSG13 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. 7 Enhanced Areas

11/7/05Nels Beckman, SSSG14 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 7 Enhanced Areas

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

11/7/05Nels Beckman, SSSG16 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 collection 4 –~50% cpu overhead –1.5X memory overhead. 7 Enhanced Areas

11/7/05Nels Beckman, SSSG17 So No Heap? Now What? RTSJ has multiple thread types –Thread –RealtimeThread –NoHeapRealtimeThread Memory Management

11/7/05Nels Beckman, SSSG18 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 Memory Management

11/7/05Nels Beckman, SSSG19 Scoped Memory Scopes have fixed lifetimes Lifetime starts here: –scopedMemArea.enter() { … } Lifetime ends: Memory Management

11/7/05Nels Beckman, SSSG20 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 Memory Management

11/7/05Nels Beckman, SSSG21 Scope Nesting Scopes can be nested –scopedMemArea.enter() {... anotherScope.enter() { }... } Memory Management

11/7/05Nels Beckman, SSSG22 Memory Safety Must ensure –No dangling pointers –Objects can’t refer to shorter lived objects An RTSJ must ensure this with run-time checks heapimmortal child parent Memory Management

11/7/05Nels Beckman, SSSG23 Common Scoped Memory Patterns Scoped Loops –Used when temporary information created at each iteration of a loop –eg.) void mainLoop() { while(true) {... }} Memory Management

11/7/05Nels Beckman, SSSG24 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 );} Memory Management

11/7/05Nels Beckman, SSSG25 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 Memory Management

11/7/05Nels Beckman, SSSG26 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? } Memory Management

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

11/7/05Nels Beckman, SSSG28 Some Proposed Techniques 1.Scoped Types for Real-Time Java, Vitek et. al. 2.Ownership-types for Safe Region-Based Memory Management in Real-Time Java, Boypati, et al. 3.Cyclone: A Safe Dialect of C All proposed techniques integrate memory location into the type system. Memory Management

11/7/05Nels Beckman, SSSG29 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! Memory Management

11/7/05Nels Beckman, SSSG30 Sharing Data Between Threads finalize() Memory Management

11/7/05Nels Beckman, SSSG31 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! Memory Management

11/7/05Nels Beckman, SSSG32 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 RTSJ Commentary

11/7/05Nels Beckman, SSSG33 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! RTSJ Commentary

11/7/05Nels Beckman, SSSG34 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. RTSJ Commentary

11/7/05Nels Beckman, SSSG35 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! RTSJ Commentary

11/7/05Nels Beckman, SSSG36 Proposed Research Directions Currently, reading up on type systems that help us to bound resource usage RTSJ Commentary

11/7/05Nels Beckman, SSSG37 Conclusion: Thanks for your attention I hoped you learned something about Real- Time/RTSJ!

11/7/05Nels Beckman, SSSG38 References 1.Bollella, G., Canham, T., Carson, V., Champlin, V., Dvorak, D., Giovannoni, B., Indictor, M., Meyer, K., Murray, A., and Reinholtz, K 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 , 2003). OOPSLA '03. ACM Press, New York, NY. 2.Bollella, G.; Gosling, J. The real-time specification for Java Computer, Vol.33, Iss.6, Jun 2000 Pages: Douglass, B. P Doing hard time: developing real-time systems with UML, objects, frameworks, and patterns. Addison-Wesley Longman Publishing Co., Inc. 4.Tian Zhao, James Noble, Jan Vitek. "Scoped Types for Real-Time Java," rtss, pp , 25th IEEE International Real-Time Systems Symposium (RTSS'04), Pizlo F, Fox JM, Holmes D, Vitek J. “Real-Time Java Scoped Memory: Design Patterns and Semantics.”