Patterns and Tools for Achieving Predictability and Performance with

Real-time Java

Presenter: Ehsan Ghaneie

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

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

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

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

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

Design Patterns

Immortal Singleton Wedge Thread Memory Pool Encapsulated Method Multi-scoped Object Memory Block

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

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

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

Encapsulated Method

Avoids unnecessary memory allocations in the current scope

Allows for allocation of objects that represent intermediate results in a temporary scope

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

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

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

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

ExecuteInRunnable

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

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

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

Scoped Memory Structure of RTZen

Performance

RTZen– Implemented using RTSJ

JacORB– Regular Java ORB

TAO– Efficient, predictable, widely used open-source

real-time CORBA ORB for C++

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

Real-time Java vs. C++

Jitter is almost the same RTZen is still slower than TAO

– Overhead of RTSJ, and Java VMs

Conclusion

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.