Real-Time Java

1
Real-Time Java

• Angelo Corsaro
• corsaro_at_cse.wustl.edu

Department of Computer Science Washington
University One Brookings Drive Box 1045 St.
Louis MO, 63130 USA
2
Outline

• Introduction
• Real-Time Java Basics
• Generative Programming
• Performances
• Concluding Remarks

3
State of the Art

• Most of the real-time embedded systems are
  currently developed in C, and increasingly also
  in C

C

• While writing in C/C is more productive than
  assembly code, they are not the most productive
  or error-free programming languages

• C is a feature rich, complex language with a
  steep learning curve, which makes it hard to find
  and retain experienced real-time embedded
  developers who are trained to use it well

• It is becoming increasingly difficult to find
  C/C programmers or to retain them

• Companies are starting to struggle with the
  maintenance costs pf C/C applications

4
State of the Art

• Java is gaining wide acceptance in different
  application domains thanks to its
• Safety
• Simplicity
• Productivity

• It is becoming relatively easy to find well
  trained Java Programmers

• There is the diffused and increasing perception
  that Java is Fun and C/C is not

• Due to its productivity and maintainability, Java
  is becoming more and more appealing to the
  embedded and (soft) real-time market.

5
Java Limitations

• Conventional Java is unsuitable for developing
  real-time systems

• The scheduling of Java threads is purposely
  under-specified (so to allow easy implementation
  of JVM on as many platform as possible)

• The GC can preempt for unbounded amount of time
  Java Threads

• Java provides coarse-grained control over memory
  allocation, and it does not provide access to raw
  memory

• Java does not provide high resolution time, nor
  access to signals, e.g. POSIX Signals

6
Java Limitations

• Conventional Java is unsuitable for developing
  real-time systems

• The scheduling of Java threads is purposely
  under-specified (so to allow easy implementation
  of JVM on as many platform as possible)

• The GC can preempt for unbounded amount of time
  Java Threads

• Java provides coarse-grained control over memory
  allocation, and it does not provide access to raw
  memory

• Java does not provide high resolution time, nor
  access to signals, e.g. POSIX Signals

7

• Whats the real problem in making Java Real-Time?

8
Java and Garbage Collection

• One of the main hurdle for making Java usable in
  Real-Time systems comes from its garbage
  collected nature
• While developer like the facilities provided by
  the GC, they cannot afford the unpredictability
  that they introduce
• At one extreme some Garbage Collectors (GC) work
  in a stop the world and collect fashion

• Recently, some Garbage Collection algorithms
  have been proposed that reasonably bound the
  delay experienced by the mutator, however these
  require either extra hardware, or double extra
  heap space or both

9
Java and Garbage Collection

• The Expert Group that designed the Real-Time
  Specification for Java, was faced with the
  problem of providing automatic memory management
  which would be usable by real-time applications
• Based on the state of the art of GC algorithms,
  the Expert Group decided to provide a safe way of
  circumventing the GC, while maintaining automatic
  memory management
• To make the problem more challenging, one of the
  requirements was that no extension to the
  language syntax was allowed
• As described next, the Expert Group based its
  solution on Memory Regions

10
Road Map

• Introduction
• Real-Time Java Basics

11
Real-Time Java

• The Real-Time Specification for Java (RTSJ)
  extends Java in the following areas
• New memory management models that can be used in
  lieu of garbage collection
• Access to physical memory
• Stronger semantics on thread and their scheduling
• Asynchronous Event handling mechanism
• Scheduling Service
• Timers and Higher time resolution

12
Real-Time Java

• The Real-Time Specification for Java (RTSJ)
  extends Java in the following areas
• New memory management models that can be used in
  lieu of garbage collection
• Access to physical memory
• Stronger semantics on thread and their scheduling
• Asynchronous Event handling mechanism
• Scheduling Service
• Timers and Higher time resolution

13
Real-Time Java

• The Real-Time Specification for Java (RTSJ)
  extends Java in the following areas
• New memory management models that can be used in
  lieu of garbage collection
• Access to physical memory
• Stronger semantics on thread and their scheduling
• Asynchronous Event handling mechanism
• Scheduling Service
• Timers and Higher time resolution

• The RTSJ does not extend syntactically the Java
  language, but simply strengthen the semantics of
  certain Java features, and adds libraries classes

14
RTSJ Memory Model

• RTSJ extends the Java memory model by providing
  memory areas other than the Heap
• The model used by the RTSJ is inspired to Memory
  Regions

• These memory areas are characterized by
• Lifetime of the object allocated within the
  memory area, and
• The allocation time
• Objects allocated in the ImmortalMemory are
  guaranteed to exist as long as the JVM
• Objects allocated in Scoped Memories are not
  garbage collected instead a reference counted
  mechanism is used to detect when all the objects
  allocated in the scope can be reclaimed

15
Scoped Memory Access Rules

• The rules that govern the access to the scoped
  memory are the following
• Only Real-Time Threads can allocate memory in a
  region different than the heap
• A new allocation context or scope is entered by
  calling the MemoryArea.enter() method or by
  starting a new real-time thread whose constructor
  was given a reference to a scoped memory instance
• Once a scoped memory is entered all the
  subsequent use of the new operator will allocate
  memory from the current scope
• When the scope is exited by returning from the
  MemoryArea.enter() all subsequent use of the new
  operator will allocate memory from the enclosing
  scope
• A Real-Time Thread thread is associated with a
  scope stack containing all the memory areas that
  the thread has entered but not yet exited

16
Scoped Memory Behaviour Rules

• The rules that govern the scoped memory behaviour
  are the following
• Each instance of the class ScopedMemory has to
  maintain a reference count of the number of
  threads active in that instance
• When the reference count of the ScopedMemory
  drops to zero, all the objects in the area are
  considered unreachable and candidates for
  reclamation
• Each ScopedMemory has at most one parent defined
  as follows. For a ScopedMemory pushed on a scope
  stack its parent is the first ScopedMemory
  below in on the stack if it exists the primordial
  scope otherwise. A scope that is not pushed on
  any stack ha no parent

17
Single Parent Rule

• The RTSJ defines the single parent rule so to
  make sure that a thread can only enter scopes
  that will live at least as much as the outer
  scopes

• The single parent rule is enforced at the point
  in which a real-time thread tries to enter a
  scoped memory.
• Traditional algorithms have O(n) time
  complexities, Corsaro and Cytron have recently
  shown how to perform this test in O(1)

18
Memory Reference Rules

• The RTSJ imposes a set of rules that govern the
  validity of references across memory areas
• A reference to an object allocated in a
  ScopedMemory cannot be allocated in the Java heap
  or in the Immortal memory
• A reference to an object allocated in a
  ScopedMemory m can be stored in an object
  allocated in a ScopedMemory p only if p is a
  descendant scope of m
• Memory reference checks are performed potentially
  at each store so the algorithm used to performs
  the checks should be predictable and efficient

19
Scoped Memory An Example
import javax.realtime. public class SMSample
public static void main(String args)
Runnable logic new Runnable() public
void run() MemoryArea ma2 new
LTMemory(128 1024, 128 1024)
Runnable nestedLogic new Runnable()
public void run() A a new A()
m2.enter(nestedLogic) Mem
oryArea ma1 new LTMemory(512 1024, 512 s
1024) RealtimeThread rtThread new
RealtimeThread(null, null, null, ma1, null,
logic) rtThread.start()
20
Memory Reference Checking

• Every compliant JVM has to perform memory
  reference checks in order to maintain Java
  safety, avoiding memory leaks and dangling
  pointers
• Some memory reference checking can be eliminated
  at compile time by pointer escape analysis
• Undecidability issues imply that some, perhaps
  many, checks still need to be performed at
  run-time
• Poor implementation of these checks could
  adversely impact performances and predictability
• Solution available on literature were not
  suitable for many reasons, mostly because they
  would lead to problem in code timing analysis

21
Memory Reference Checking

• Recently, Corsaro and Cytron have proposed an
  algorithm based on type theory for performing
  this test in O(1), as opposed to the O(n)
  solution available in literature

22
Real-Time Threads

• The RTSJ extends the Java threading model with
  two new types of thread
• RealtimeThread
• NoHeapRealtimeThread
• NoHeapRealtimeThread cannot refer to any object
  allocated on the heap. This make it possible for
  this kind of thread to preempt the GC
• Real-Time Threads provide facilities for periodic
  computations

• For a Real-Time Thread it is possible to specify
• Release Parameters
• Scheduling Parameteres
• Memory Parameters
• Thread execution is managed by the associated
  scheduler

23
Event Handling

• The RTSJ defines mechanisms to bind the execution
  of program logic to the occurrence of internal
  and/or external events
• The RTSJ provides a way to associate an
  asynchronous event handler to some
  application-specific or external events.

• The AsyncEventHandler class, does not have a
  thread permanently bound to itnor is it
  guaranteed that there will be a separate thread
  for each AsyncEventHandler
• The BoundAsyncEventHandler class has a real-time
  thread associated with it permanently

24
Scheduling

• The RTSJ provides a policy independent scheduling
  framework
• Only Schedulable entities are considered for
  scheduling and feasibility purpose
• The responsibility of the scheduling framework
  are
• Schedule Schedulable Entities
• Performing Feasibility Analysis
• Schedule appropriate handlers in case of error
• Different schedulers can potentially be used
  within a running applications
• The default scheduler is a Priority-Preemptive
  scheduler that distinguish 28 different
  priorities

• Schedulable entities are characterized by
• Scheduling Parameteres
• Release Parameters
• Memory Parameters
• Erroneous situations are handled by event handler
  associated with Release Parameters
• Overrun Handler
• Deadline Miss Handler

25
Time and Timers

• Real-time embedded systems often use timers to
  perform certain actions at a given time in the
  future, as well as at periodic future intervals
• The RTSJ provides two types of Timers
• OneShotTimer, which generates an event at the
  expiration of its associated time interval, and
• PeriodicTimer, which generates events periodically

• Along with timers the RTSJ provides a set of
  classes to represent and manipulate high
  resolution time, and specifically
• Absolute Time
• Relative Time
• Rational Time

26
Outline

• Introduction
• Real-Time Java Basics
• Generative Programming

27
Does One Size Fits All?

• While the RTSJ represents an ambitious step
  toward improving the state of the art in embedded
  and real-time system development, there are a
  number of open issues
• The RTSJ was designed with generality in mind,
  while this is a laudable goal, generality is
  often at odds with the resource constraints of
  embedded systems

28
Does One Size Fits All?

• While the RTSJ represents an ambitious step
  toward improving the state of the art in embedded
  and real-time system development, there are a
  number of open issues
• The RTSJ was designed with generality in mind,
  while this is a laudable goal, generality is
  often at odds with the resource constraints of
  embedded systems

• Providing developers with an overly general API
  can actually increase the learning curve and
  introduce accidental complexity in the API itself
• For example, the scheduling API in RTSJ was
  designed to match any scheduling algorithm,
  including RMS, EDF, LLF, RED, MUF, etc.
• While this generality covers a broad range of
  alternatives it may be overly complicated for an
  application that simply needs a priority
  preemptive scheduler

29

• Can we do any better then this?

30

• Can we provide the needed flexibility and
  extensibility, without putting undue burden on
  developers?

31

• The Answer is

32
Generative Programming

• Generative Programming aims at building
  generative models for families of systems and
  generate concrete systems from these models

• Generative Programming brings the benefit of
  Economies of Scope to software engineering, where
  less time and effort are needed to produce a
  greater variety of products

33
Generative Programming

• Generative Programming aims at building
  generative models for families of systems and
  generate concrete systems from these models

• Generative Programming brings the benefit of
  Economies of Scope to software engineering, where
  less time and effort are needed to produce a
  greater variety of products

Classical Approach
Design Space
34
Generative Programming

• Generative Programming aims at building
  generative models for families of systems and
  generate concrete systems from these models

• Generative Programming brings the benefit of
  Economies of Scope to software engineering, where
  less time and effort are needed to produce a
  greater variety of products

Classical Approach
Generative Programming Approach
Design Space
Design Space
35
Generative Programming

• Generative Programming (GP) makes it possible to
  develop Software Systems that are amenable to
  customization of behavior and protocols (e.g.,
  APIs), via automatic code generation and
  composition
• Using a GP approach, the development of
  middleware, such as RTSJ or Real-time CORBA, need
  not lead to a single implementation. Instead, it
  can provide a set of components and configuration
  knowledge that can be used to generated a
  specific implementation based on user-defined
  specifications

If we consider the RTSJ scheduling API example,
for instance, application developers that need a
simple priority preemptive scheduler could use
generative programming to specify this as a
requirement. The outcome of the generation
process would then be a Realtime Java platform
that exposed only the API needed for a
priority-based scheduler and whose implementation
was also optimized for priority-based schedulers.
36
jRateThe Chameleonic RTSJ

• jRates is an extension of the GCJ runtime system
  that provides a subset of the RTSJ features such
  as
• Realtime Threads
• Scoped Memory
• Asynchrony
• Timers

• jRates goals
• Use a Generative Programming approach to provide
  a Chameleonic Real-Time Java, which can adapt
  to its target environment in term of API and
  functionalities
• AOP techniques will be used to produce an
  untangled, and pick what you need RTSJ
  implementation
• AspectJ, C Templates, Python, will be used to
  do AOP in the Java and C portion of jRate
  respectively
• Provide higher level programming model to
  developers
• Provide advanced scheduling services

37
Generative Real-Time Java
38
Outline

• Introduction
• Real-Time Java Basics
• Generative Programming
• Performances

39
RTJPerf Tested Platforms

• RTJPerf is a benchmarking suite for RTSJ
  compliant platforms that focuses on
  Time-efficiency performance indexes.
• RTJPerf provides a series of tests based on
  synthetic workload
• RTJPerf currently covers the following RTSJ
  areas
• Memory
• Threading
• Asynchrony
• Timers

• RTSJ Reference Implementation, developed by
  TimeSys
• Provides all the mandatory RTSJ features

• jRate, an Open Source RTSJ-based extension of the
  GCJ runtime system
• Currently provide only a subset of the mandatory
  RTSJ features

All test were run on a Pentium III 766MHz running
TimeSys Linux/GPL
40
Allocation Time Test

• Objective
• Determine the allocation time for different kind
  of ScopedMemory provided by the RTSJ

• Technique
• Allocate vector of characters for different sizes
  ranging from 32 to 16K bytes

• Tested Platform
• RTSJ RI
• jRate

• Test Parameters
• 1,000 Sample for each chunk size were collected

41
Test Statistics 1/3
42
Test Statistics 2/3
43
Test Statistics 3/3

• As the size of the chunk allocated increases the
  speedup of jRates CTMemory over the RI LTMemory
  can be as much as 95.
• The CTMemory speedup over the LTMemory grows
  linearly with the size of the chunk being
  allocated

44
Dispatch Delay Latency

• Objective
• Measure the time elapsed from when an event is
  fired up to when its associated handler is invoked

• Technique
• Associate an handler with and AsynchEvent, fire
  repeatedly in lock step mode the event. Measure
  the time elapsed between the firing of the event
  and the handler activation

• Tested Platforms
• RTSJ RI, jRate

• Test Parameters
• 2,000 samples of the dispatch delay time were
  collected

45
Sample Trace

• jRates AsynchEventHandler and BoundAsynchEventHan
  dler have similar performances
• The sample trace shows a very predictable
  dispatch delay for jRate
• RIs BoundAsynchEventHandler provide a quite
  good dispatch delay latency, but is less
  predictable

• RIs AsynchEventHandler expose a strange
  behaviour (caused perhaps by a resource leaks
  associated with thread management)
• The Dispatch Latency grows linearly with the
  number of event fired

46
Test Statistics

• jRates handlers have worst cases performances
  very close to the average and 99 case
• jRates handler behavior quite predictable, as
  the low std. dev. indicates
• RIs BoundAsynchEventHandler has a 99 behaviour
  that is very close to the average case while the
  worst case behaviour is a little bit off.
• RIs AsynchEventHandler exposes an odd behaviour
  (as shown previously), so its data is not very
  representative

47
Concluding Remarks

• Real-Time Java is a quite intriguing technology,
  but there is still quite a bit of RD to be done
  in order to make it sound
• Many aero-spatial companies and federal research
  institution have placed big bets on Real-Time
  Java, some of these are
• BOEING
• NASA
• Air Force Research Laboratory
• DARPA
• Generative Programming techniques are an
  interesting topic, and more research is needed in
  this area in order to understand
• GP Pattern and Pattern Languages
• GP Methodologies
• GP Techniques and Tools
• jRate provide a vast playground for experimenting
  with Real-Time Java features as well as with GP
• GP provides a good balance between flexibility
  and performance/efficiency

48
References

• jRate Web
• http//tao.doc.wustl.edu/corsaro/jRate
• Papers on jRate
• http//tao.doc.wustl.edu/corsaro/papers.html
• Real-Time Java Expert Group
• http//www.rtj.org
• Reference Implementation
• http//www.timesys.com
• Mailing List
• rtj-discuss_at_nist.gov
• Related Work
• GCJ (http//gcc.gnu.org)
• FLEX Compiler, MIT
• OVM Virtual Machine, Purdue University
• JamaicaVM, European Space Agency
• PERC, NewMonics