Patterns and Tools for Achieving Predictability and Performance with Real-time Java

1. Patterns and Tools for Achieving Predictability and Performance with Real-time Java Presenter: Ehsan Ghaneie

2. Java and Real-Time Systems • Unable to offer real-time systems’ required Quality of Service (QoS) guarantees of predictability • Under-specified scheduling semantics of Java threads can lead to situations where the most eligible thread is not allowed to run • The Java garbage collector can preempt any other Java thread, thus causing unpredictably long preemption latencies

3. Real-time Specification for Java (RTSJ) • Maintains main advantages of Java such as ease of use, portability, and native thread support • Stronger guarantees on thread semantics • Real-time threads (RTT) • No heap real-time threads (NHRTT) • Both have higher priority than regular Java threads • Offers predictable memory management needed for real-time applications • Heap Memory • Immortal Memory • Scoped Memory

4. Scoped Memory • Scoped Memory blocks expire when there are no more threads executing in their region • Can cause memory waste if short-lived objects are in the same scope as long-lived objects => • Nested scopes: • Longer-lived objects should be created in ancestor scopes • Shorter-lived objects should be created in appropriate child scopes

5. Side Effects of Scoped Memory • Adds complexity to the design of real-time systems written in Java • Tight restrictions imposed on cross-scope memory access => Memory access rules • Lifetime rule • Single parent rule

6. Side Effects of Scoped Memory • Explicit control of memory creates the potential to have memory leaks. • Lifetime of an application: • Initialization • Operation • Termination • Memory leak is defined as allocation of non-recyclable objects in immortal or scoped memory areas during operation phase • Recovering from memory leaks is an expensive operation

7. Design Patterns • Immortal Singleton • Wedge Thread • Memory Pool • Encapsulated Method • Multi-scoped Object • Memory Block

8. Immortal Singleton • Adaptation of classical Singleton pattern • Allows for creating a unique instance of a class from immortal memory • Can be accessed from any memory area

9. Wedge Thread • Prevents premature reclamation of a scoped memory area by controlling its lifetime • Consist of a real-time thread that enters a scope and blocks • Waits for a signal to exit the area

10. Memory Pool • Set of instances of a given class pre-allocated in a specific memory area • Pooled objects are generally mutable • When an object is required, it will be taken from the pool • When an object is not required any longer, it will be returned to the pool

11. Encapsulated Method • Avoids unnecessary memory allocations in the current scope • Allows for allocation of objects that represent intermediate results in a temporary scope

12. Multi-scoped Object • Allows transparent access of an object regardless of the originating region of the callee • Performs the proper memory scope traversal to ensure that a given method is called from the correct scope

13. Memory Block • Allows pooling, via serialization, of objects of varying size in a byte array block allocated from immortal memory • Disadvantages • Required explicit memory management • (De)serialization incurs additional overhead

14. Separation of Creation and Initialization • Problem: • Creation of objects in another memory area requires the use of Java reflection • Can become inefficient when creating objects with parameters • Solution: • Define classes with default constructor • Provide accessor methods

15. Cross-scope Invocation • Problem: • Elaborate memory traversal must be performed to invoke a method on an object that is not in the calling object’s scope stack • Solution • ExecuteInRunnable class has been developed to simplify cross-scope invocation

16. ExecuteInRunnable

17. Immortal Exception • Problem: • Exceptions may need to be thrown and handled in different memory areas • Solution • A “Factory” class that creates exception objects in created in immortal memory • Immortal singleton pattern is used to cache the exception objects so they can be re-thrown

18. Immortal Façade • Problem: • Complex scoping structures of large applications makes development and maintenance difficult • Solution • Façade class encapsulated the logic that handles the cross-scope invocation • Implementation class implements the actual logic behind the façade • Based on Gang of Four Façade design pattern

19. RTZen • The first implementation of Real-time CORBA middleware in real-time Java • Goals • Provide a high degree of predictability while maintaining good performance • Maintain ease of use for the application developer by hiding the implementation details • Be compliant with both RTCORBA, and RTSJ to offer portability

20. Scoped Memory Structure of RTZen

21. Performance • RTZen • Implemented using RTSJ • JacORB • Regular Java ORB • TAO • Efficient, predictable, widely used open-source real-time CORBA ORB for C++

22. Real-time vs. Regular Java • Operating system: TimeSys Linux GPL 4.1 • Based on the Linux kernel 2.4.21 • Non-real-time JVM: Sun JDK 1.4 JVM • Real-time Java Platform: jRate

23. Real-time Java vs. C++ • Jitter is almost the same • RTZen is still slower than TAO • Overhead of RTSJ, and Java VMs

24. Conclusion

25. Thank You! • References • Krishna Raman, Yue Zhang, Mark Panahi, Juan A. Colmenares and Raymond Klefstad. Patterns and tools for achieving predictability and performance with real-time Java. In Proc. 11th IEEE Int'l Conference on Real-Time and Embedded Computing Systems and Applications (RTCSA 2005). Hong Kong, China. August 2005. • Krishna Raman, Yue Zhang, Mark Panahi, Juan A. Colmenares, Raymond Klefstad, and Trevor Harmon. RTZen: highly predictable, real-time Java middleware for distributed and embedded systems. In Proc. ACM/IFIP/USENIX 6th Int'l Middleware Conference (Middleware 2005). Grenoble, France. December 2005.