Java Real-Time Distributed Processing
over Chorus/OS
Christophe Lizzi
CS Technologies Informatiques
CNAM, CEDRIC lab.
Outline
• Motivations
• Our vision
• Real-time Java
•
• Operating system and network supports
• Java real-time extensions
Motivations
Current industrial control systems
• various networks
- fieldbuses, control buses, LANs, analog links - QoS, performances, service model
• various environments
- hardware: workstations, embedded systems, PLCs
- software: operating systems, APIs, programming languages
• various bandwidth and QoS demanding applications
- command/control data, reporting, audio/video streaming for quality control or failure localization
Heterogeneity is the key problem
Our vision
An open, integrated, homogeneous distributed real-time environment How?
• by using ATM and Java as the core technologies of the system
Homogeneous networking infrastructure: ATM
• integrated, scalable, open, flexible QoS, easy integration
Homogeneous distributed processing environment: Java
• binary portability, high-level abstractions, security, modularity
Challenges
• end-to-end performance guarantees over ATM
• Java real-time processing
Java
What is Java?
• an object-oriented programming language
• a runtime system
• an application programming interface (JDK classes)
Why Java?
• the Java language and the Java platforms support application portability
• higher level of abstraction
• security mechanisms
• Java is designed to support component integration and reuse
Beneficts
• portability, reliability, high level application design
Drawback
Real-time Java
Why Java in real-time systems?
• Industrial applications run on the entire spectrum of system platforms
- from workstations with standard operating systems to microcontrollers without an OS in embedded systems
- lots of specialized and costly developement systems - various abstractions, services, semantics
• impacts portability, integration, development costs of applications
Real-time Java
• retain the benefits of the Java language
- portability, high level of abstraction
• add deterministic temporal behavior
- real-time scheduling, synchronization, communications
Problems raised by Java in a real-time environment
Thread scheduling
• scheduling policies are JVM-dependent
• need for a high level model of tasks and temporal constraints
Thread synchronization Code interpretation
• dynamic class loading, verification and link edition delays are not predictable
Memory management
• interferences with the garbage collector
Performances
• just-in-time compiling, dynamic optimization
Related work and products
PERC from NewMonics
• specific compiler, JVM and core classes
• uses an extended dialect of Java
• new keywords: atomic and timed
- enable to express required temporal behavior
• rate monotonic scheduling
• real-time incremental garbage collection
- can be interrupted by real-time threads
• proprietary classes to access to physical memory, I/O ports
and interrupt handlers
EmbeddedJava and JavaOS for Consumers from Sun, JBED from Oberon, Kaffe...
• subsets of Java 1.1 + proprietary packages
Standardization (?) efforts
Our approach
Enabling end-to-end deadline inheritance
• uniform model of temporal constraints
- message and task scheduling
Adding real-time capabilities to our JVM virtual machine
• support for Java real-time scheduling and synchronization
• enhanced Java Native Interface
• access to real-time communications over ATM
• access to hardware resources through native methods
Underlying real-time distributed operating system
• Chorus/OS from Sun Microsystems
Overview
GNU Japhar JVM GNU Japhar JVM
ChorusOS ChorusOS EDF-scheduled Java thread end-to-enddeadline inheritance RT-IPC server ATM driver RT-IPC server ATM driver RT-binding EDF-scheduled Java thread shared buffers message handler shared buffers
Operating System Support
Chorus/OS
• microkernel-based distributed real-time system
• now commercialized by Sun Microsystems
• foundation of the JavaOS for Consumer product
Modularity
• made of building blocks selected according to application requirements
• selected components determine the core features of the system
• memory model, scheduling policies, available APIs
Customization
• support of ATM networks
• deadline-based scheduling
• real-time IPC
ATM support
ATM networking
• a set of switches connected by point-to-point links
• cell based switching and asynchronous multiplexing
Why ATM?
• high bandwidth
• connection oriented
• native end-to-end QoS support
• scalability
- flexible topology, distance (LAN, MAN, WAN), bandwidth
• open technology
Why ATM in real-time systems?
• integrated traffic transport
• one network technology
Enforcement of QoS
CBR and rt-VBR service categories are suitable for time sensitive traffic
• open loop control: congestion avoidance via cell scheduling
Traffic contract
• traffic specification: PCR, SCR, MBS
• QoS specification: maxCTD, CDV, CLR
The network commits to support the QoS for all compliant connections Separation of the network provider and the user
• ATM comes from the telco world
• protect the network and its performance
Leads to traffic contract, admission control, shaping, policing and scheduling
Enforcement of QoS (cont.)
Traffic contract
• user description of traffic and requested QoS
• network connection admission control
• require traffic models and conformance definitions
Shaping
• make sure the traffic passes the policer’s conformance test
Policing
• Usage Parameter Control at UNI = test for compliance
• GCRA algorithm = leaky bucket
Scheduling
• which cell to send?
Java real-time support
Thread scheduling and synchronization
• Earliest Deadline First scheduling
- release time, absolute deadline, worst-case execution time, period
• support for basic priority inheritance protocol
Communications
• location-transparent real-time IPC service
- basic concepts inherited from the regular Chorus IPC service
• binding between RT-IPC ports is subject to network admission control
Enhanced Java Native Interface
• Java objects may be moved by the garbage collector, so copies are supplied
- data copies limit the JNI performances
• enabling the sharing of data between Java and native methods
Real-time extensions
Thread scheduling
class SampleThread extends PeriodicEdfThread { public SampleThread() { setReleaseTime( 0 ); setAbsoluteDeadline( 1000000 * 1000000 ); setWorstCaseExecTime( 100 * 1000000 ); setperiod( 100 * 1000000 ); setmaxReleaseCount( 10 ); }
public void edfRun() { doSomethingHere(); }
public static void main(String[] args) { new SampleThread().start();
} }
Real-time extensions (cont.)
Communications
• similar to the standard Chorus IPC framework
• exchange of RT-messages through RT-ports
Service
• RT-messages convey a deadline
• required explicit binding of RT-ports between any interactions
• binding is subject to negociation and admission control
• deadline-scheduled handlers are associated to RT-ports
End-to-end deadline inheritance
• an absolute deadline is propagated from the sender to the receiver
of an RT-message
• RT-message deadline is set by the user or inherited from the sender thread
Real-time extensions (cont.)
Java Native Interface
• real-time communication relies on native methods
• heavy transfers of serialized data accross the JNI interface
JNI design
• the JNI spec prohibits memory sharing between native and Java objects
• Java objects may be moved by the garbage collector
During JNI invocations involving arrays:
• pin down the Java object during the execution of the native code, or
• supply a non-moveable copy to the native side
- if updated data are returned, then another copy is performed
Real-time extensions (cont.)
Enhanced JNI interface
• enable the sharing of data between Java and native methods, boosting
performances
• arrray body not allocated in the Java heap, but using native DMA’able pages
public class SampleClass {
public byte shared[];
public void sampleMethod() { shared = nativeAllocMethod(); shared[ 5 ] = 123;
} }
Java heap
Java virtual machine native code
ChorusOS memory pages
jbyteArray attribute SampleClass instance
JNI interface
native body of
shared byte array
123
Memory Management
Garbage collection
• Java exempts the programmer to explicitly release the allocated memory
• done by the garbage collector
GC techniques
• reference counting
• mark and sweep
• copying
Real-time Java requires incremental GC techniques
• memory is collected while the reference graph is explored by the GC
- the graph can be altered by the application while it is being explored - the GC can be interrupted
Dedicated non-copying GC algorithms
Memory Management (cont.)
The overhead induced by garbage collection can be unacceptable for some classes of real-time applications
• real-time GC is not included in the current draft specs of the RTJWG
- treated as and optional, vendor-specifc, extension
Allocation contexts
• partition of the memory heap
• expresses the lifetime of the objects it contains
- objects are automatically reclaimed when their allocation context is destroyed
• default per-thread allocation context
• a class may implement the following interface to indicate that all objects
instantiated by its methods must be allocated in a specific context
interface CoreAllocator {
public CoreAllocationContext allocationContext(); }
- the allocating context being used is represented by the object returned by allocationContext()
Further Work
RMI are not yet supported
• serialisation of composite objets is partially missing
• stream-based interactions only
Higher abstraction model
• the Sun JINI environment
• the Jonathan flexible ORB
- J.B. Stefani’s team at France Telecom CNET
Towards an extensible Java-based SCADA environment
Conclusion
Heterogeneity of industrial systems is the key problem
• various computing environments connected by various networks and running
various QoS-demanding distributed applications
• negative impact on scalability, integration, maintenance, cost
Our proposal
• homogeneous virtual computing environments connected by one network
• core technologies: Java and ATM
Benefits
• integrated, scalable networking with native QoS support
• high-level, portable Java computing environment
Promising approach (?), but these technologies are still in infancy
• required support for real-time communications over ATM
