Real-time core extensions assure Java use

Because it was recently approved as an International Standards Organization PAS submitter, the J Consortium can submit its Real-Time Core Extensions specification to ISO for standardization. The Real-Time Core Extensions are structured as a plug-in to augment the capabilities of existing off-the-shelf Java virtual machines. Key attributes include the ability to achieve throughput, latency, predictability and memory footprints that are comparable to those stemming from the use of C++ in commercial real-time operating systems today.

The J Consortium specification addresses all of the core requirements identified in the National Institute of Standards and Technology requirements document, along with a number of additional self-imposed requirements agreed upon by the members of the Real-Time Java Working Group.

During the first six months or so of the NIST requirements meetings, a range of real-time needs was discussed. The working group decided to identify a subset of core requirements to be addressed in an initial specification. In general, the sentiment was that the real-time extensions should:

• provide services comparable to those provided by commercially available RTOSes;

• be reasonably straightforward to implement;

• provide a foundation upon which more sophisticated, higher-level real-time profiles can be constructed, and

• not endeavor to advance the state of the art in real-time programming.

The significance of the last point is to emphasize that the real-time core extensions should support real-time programming in the styles that are typical of the day. To address all of the requirements identified in the NIST document is to enable and encourage new styles of real-time programming that represent radical departures from the current state of the practice.

The NIST core requirements leave considerable room for interpretation and ambiguity. To establish a foundation for building its draft specification, the Real-Time Java Working Group established a number of clarifying principles to augment the list of requirements.

First, the core system must support limited cooperation with baseline programs running on the same Java virtual machine, with the integration designed so that neither environment need degrade the performance of the other. (The term "baseline" refers to the non-real-time version of the Java language, as it has been defined by Sun Microsystems Inc.)

Also, it must support limited cooperation with programs written according to the specifications for higher-level real-time Java profiles in environments that implement them, with the integration designed so that neither environment need degrade the performance of the other.

Next, the semantics of the real-time core shall be sufficiently simple that interrupt-handling latencies and context-switching overheads for core programs can match the latencies and context-switching overheads of today's RTOS products running programs written in C or C++. And, the core specification shall enable implementations that offer throughputs essentially the same as those realized by today's optimizing C++ compilers, except for semantics differences required, for example, to check array subscripts.

Core programs need not incur the run-time overhead of coordinating with a garbage collector. Among the overheads that the core specification shall not require are:

1. Read and write barriers to access dynamically allocated objects and stack locations;

2. Garbage collection scanning of run-time stacks and,

3. Pointer identification information required to support garbage collection.

Baseline components and components written for yet-to-be-defined higher-level real-time profiles shall be able to read and write the data fields of objects that reside in the core object space, where access could be restricted to accessor-and-setter methods. Core programs need not be able to read or write the data fields of objects that live in the baseline object space.

Security mechanisms will prevent baseline components from compromising the reliability of core components. However, core programs shall run on a wide variety of operating systems, with different underlying CPUs and integrated with different supporting baseline virtual machines. There shall be a standard way for baseline components to load and execute core components.

The core execution environment will exist in two forms, one supporting dynamic loading and unloading of core classes and the other not supporting dynamic class loading. These are known respectively as the dynamic and the static core-execution environments.

The core specification supports the ability to perform stack allocation of dynamic objects under programmer control. It shall be designed to support a small footprint, requiring no more than 100 kbytes for a typical static core-execution environment, and it shall enable the creation of profiles that expand or subtract from the capabilities of the core foundation. Finally, all core classes shall be fully resolved and initialized at the time they are loaded.

The Core Java Execution Environment is a plug-in module that can augment any Java virtual machine, enabling users to leverage the large technology investment in current virtual machine implementations, including API libraries and legacy applications, byte code verifiers, garbage collectors, just-in-time compilers and symbolic debuggers.

The Core Java Execution Environment can be configured to run without a baseline Java virtual machine, allowing developers to deploy core Java implementations in very small memory footprints (as small as 100 kbytes). One thing the Core Java Execution Environment does not support is automatic garbage collection. Programmers are required to explicitly release objects when they are done using them.

It does, however, support stack allocation of objects, under programmer control, as well as priority inheritance for synchronization and explicit lock objects. It uses the Priority Ceiling Protocol for specially designated objects. In addition, it supports signaling and counting semaphores, direct access to I/O ports and the implementation of interrupt handlers as core components.

Finally, the Core Java Execution Environment allows asynchronous events to trigger control transfer in particular tasks. Each task has the opportunity for each asynchronously signaled event to either handle the event and then resume whatever work was preempted, or to abort its current efforts.

The core real-time extensions offer much higher levels of abstraction than when programming in assembler, C or C++. The high levels of abstraction reduce the programmer's burden for low-level detail, reduce the likelihood of certain errors, shorten the time required to deliver new products to market and shrink long-term software maintenance costs.

Compared with programming in baseline notations, developing core Java applications is lower level in that it provides programmers with direct access to hardware devices and requires them to manage their own dynamic memory. Even so, many of the benefits of baseline programming are preserved by the core specification.

In particular, the core specification uses the same portable binary code representation used for baseline class files. Core developers are able to leverage commercial off-the-shelf Java development tools and can recruit developers from the large body of software engineers who have already acquired Java expertise.