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 nonrecyclable 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 preallocated 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
–

JacORB
–

Implemented using RTSJ
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.