Introduction to Java Technology:

Since we want to adapt J ava for Real time, some knowledge of J ava is necessary. Before
we get to the main points, we are going to give you a brief review to J ava Technology.
J ava language takes a lot of syntax, grammars & programming conventions from C/C++
but there is totally different mechanism to handle J ava code from the traditional C/C++
language.
J ava is a simple, object-oriented, distributed language.
J ava's syntax resembles that of C/C++
Many features added to J ava such as memory management, reusability,
extensibility, security and reliability

Java Technology:

J ava technology is more than just a programming language. It is a completely new
approach to software development. J ava Technology mainly consists two parts. J DK and
J RE. J DK help us do everything before the execution of the J ava program. The major
component of J DK is J ava compiler. J RE will do everything during the execution of J ava
program. The major component of J RE is J ava Virtual Machine:

Java Developers Kit (JDK)
- J ava compiler (.java file ->.class file)
- J ava launcher and jdb debugger
Java Run-time Environment (JRE)
- J ava platform core classes libraries
- J ava virtual machine (J VM)


Figure 1
Java Execution Process:

Picture 1 shows the "java execution process". The left part is J DK. The right part is J RE.
We should notice that J DK convert .java file to .class file.

.class file is not final machine code yet. It is virtual machine code. J VM need a second
compilation to convert virtual machine code to real machine code. We call it just in time
compiler (J IT). This greatly affects the speed of the execution. Traditionally, our C/C++
program can finish all the compilation before execution. The generated machine code
could run directly on OS or hardware. But in J ava Language, the java virtual machine is
standing in our way and adds another level of compilation to the system.

Java Virtual Machine (JVM):

J VM acts as a software emulation of a processor; it runs on top of a host operating system
(OS) and requires some native OS services to implement J avas run-time features (e.g.
multithreading, synchronization, native semaphores, dynamic memory management,
networking, graphics stacks).

J VM must be ported to each underlying OS and processor that it actually runs on (J ava
program is allowed to be cross-platform portable).

Java Benefits in Real-Time Application:

Dynamic extensibility
Reliability, Security
Code reuse and shorter development life cycles
Portability

Java Weaknesses for Real-Time Application:

As we mention, the J VM need "just in time" compilation There is No doubt that the
execution will be slow. It has been said that java is 20 times slower than C/C++. As we
know, time is critical in real-time application. That's a big disadvantage. J ava is a high-
level language; it lacks the ability to do low level control. In other words, J ava is too
heavy to load. J ava has bad resource utilization.

Speed: J ava is a semi-compiled language, much slower than a complied, native
machine-code-executed language (20 times slower than C/C++)
Hardware control, low-level input/output (I/O): J ava does not provide direct
memory access or interrupt handling, features usually required when with low-
level device drivers in real-time embedded systems.
Scalability: J ava includes a large set of mandatory, non-scalable classes. J ava
lacks the ability to tailor the OS and run-time components to exactly fit
application needs and avoid unnecessary memory usage.

Comparing to the previous issues, there are two issues that are far more critical and
significant. They are acting as obstacles for adapting java for real-time.

We all know java garbage collection mechanism will automatically clean up lost object in
the memory. An object is lost if no body is referencing it any more. But cleaning up a lost
object may trigger additional objects to be lost. J ust like a chain of objects that we don't
know in advance how many objects in the chain. Since the chain could be arbitrarily
long, it is unpredictable how much time we need to clean up this chain.

The second critical issue is Thread Scheduling. Since the J VM relies on the host
operating systems scheduler, then the operating system must be capable of real-time
scheduling. This is not true for all hosts where J VM is available. As we execute a J ava
thread, we call the start() method of the thread object. But we have no control of when
the thread will be executed. We only have a rough idea that all J ava threads are running
concurrently. In fact, the approaches we discuss later are mainly target these two critical
issues.

Two Popular Real-time Java Approaches:

1. Real-Time Core Extensions (RTCE) - Instead of modifying the whole J VM,
RTCE can be implemented as a real-time add-on working closely with an
arbitrary existing J VM.
2. Real-Time Specification for Java (RTSJ) - RTSJ implementations require
modifications of the J ava Virtual Machine (J VM) internals. The application
developer can choose the thread scheduling algorithm and there are several
strategies for memory management.

Real-Time Core Extensions (RTCE):

RTCE splits the applications into two parts: real-time part and non-real-time part. Non-
real-time part run on the standard J ava runtime environment called Baseline J ava. Real-
time parts run on a runtime environment called Core J ava. Core J ava can pre-empt
Baseline J ava anytime.


Figure 2

Core Java:

Core java runs completely outside of J VM. The Real-time kernel provide runtime
environment for Core J ava. In other words, Core java will be executing as a module in
RT kernal. "Core java" Can be used as a stand-alone runtime environment and has its
own set of class libraries, which are separated from standard J ava class hierarchy. Root of
the Core class is not java.lang.Object but org.rtjwg.CoreObject and it has a higher
priority than the Baseline J ava. Core J ava API doesn't depend on Baseline API:


Baseline API Core API




JaRTS (Java Real-Time by Siemens) Implementation:

J aRTS is an implementation of a Core J ava compiler and the RTCE libraries. Output of
the J aRTS compiler is platform independent ANSI-C code as well as J ava code for the
Baseline-Core communication. Communication between Baseline and Core is
implemented in platform dependent C files.

The prototype J aRTS compiler and runtime libraries were implemented for RTLinux. The
Core parts of an application (real-time parts) are compiled to native code running directly
on the real-time scheduler. For RTLinux the real-time code has to be compiled into
kernel modules that can be loaded dynamically. Following figure shows the whole build
process of a J aRTS real-time J ava application. Platform dependent files for RTLinux are
encircled:


Figure 3

Baseline-Core Communication:

Core J ava runs directly on the real-time kernel. Baseline J ava runs on a standard J VM on
top of the Linux kernel. We need to implement some communication routines that use the
FIFOs provided by RTLinux for communication between real-time threads and non-real-
time Linux threads. These FIFOs are accessed by native code via J NI.

Picture 4 describes the idea of RTCE. The RT environment runs on RT kernel with
higher priority. Hence, Core J ava has full control of the timing and has access to all real-
time features. The non-RT environment runs on normal J VM, and J VM runs on normal
linux kernel. Since Baseline J ava has full access of java features and can communicate
with Core J ava by special FIFOs, Core J ava can have full access of java features
indirectly.





Figure 4

Summary for RTCE approach:

RTCE resolves two critical J ava Weaknesses for Real-Time: Memory Management,
Thread Scheduling. RTCE applications can use all available J ava libraries via J NI. An
off-the-shelf J VM which is already available for most systems is used for the non-real-
time parts. This J VM can support all known J ava libraries.
It is much easier to port J aRTS to a new platform than a complex J VM implementing
RTSJ . Since J aRTS currently is a prototype implementation there is space for
improvement in terms of memory and performance.


Real Time Specifications for Java:

RTSJ Creators:

In 1998 a group of computer experts in real-time control gathered together at IBM and
Sun Microsystems by the National Institute of Standards and Technology (NIST) to
outline requirements for real-time J ava. That group was called Real-time J ava Expert
Group (RTJ EG). Their goal was to create a real time specification for java to be used by
real time programs written in java, and being executed in different plat forms. RTSJ
implementations require modifications of the J ava Virtual Machine (J VM). It suggests 7
areas to be changed in J VM.


Main Principles in Designing RTSJ:

The Real-Time J ava Expert Group (RTJ EG), setup a set of guiding principles for the
design of Real-Time Specification for J ava. Here are the principals:
1. The implementation of RTSJ should not be limited to a specific java platform or
environment. The implementation should work for all java platforms such as
Personal java, Micro J ava, J ava OS
2. Any modifications should not, prevent the execution of written non real-time
software
3. One of the most important principals in java from the beginning was the write
once run all principal. The group suggested that this principal should be followed
by the RTSJ .
4. The RTSJ not only must include the current features for real time systems, but
also be extendable in the future.
5. The most important goal was to create a predictable system, because it is the
essential part of any real time system.
6. The changes should not apply to java compiler, preventing the need for frequent
releases

JVM modifications:

Based on the guiding principle RTSJ has modified 7 areas in the original java virtual
machine:
1. Thread scheduling and dispatching
2. Memory management
3. Synchronization and resource sharing
4. Asynchronous event handling
5. Asynchronous transfer of control
6. Asynchronous thread termination
7. Physical Memory Access

1. Thread scheduling and dispatching:

Since there are many possible scheduling and dispatching algorithms, RTSJ decided that
it would allow any scheduling algorithm can be used by the programmer. However, it has
a base scheduling policy that is a pre-emptive priority scheduling with first in first out
order.

2. Memory management:

Since garbage collection is a limitation of java for real time programs, RTSJ decided that
Memory allocation and recovery specification that is independent of any particular
Garbage Collection algorithm. RTSJ has defined the exact timing requirements and
effects of GC algorithms on real time java threads. RTSJ allows memory allocation and
recovery without the need to use any GC algorithm.

3. Synchronization and resource sharing:

Most of the real time programs need to share some data, and the problem that can happen,
is the priority inversion problem. RTSJ will prevent the priority inversion problem if the
keyword synchronized is used. RTSJ uses Priority inheritance protocol by default and has
the optional priority ceiling protocol.

4. Asynchronous Event Handling:

Real time systems interact with real time world, the events that happen in the real world,
is not necessarily periodic these events can be completely asynchronous. In RTSJ there is
a way of handling the asynchronous events: Classes and objects represent things that can
happen and the logic that must be executed when those things happen. There exist
asynchronous event handlers to be executed whenever the event happens. This makes it
easy to code and handle asynchronous events.

5. Asynchronous Transfer of Control:

Real time world can change anytime and some of these changes need an immediate
action from a real time system. So it must be prepared to transfer execution to a different
location. interrupt() method is allowed to occur anywhere in the code instead of only in
certain blocking calls.

6. Asynchronous thread termination:

Again due to the sudden changes in the real world, a real time system must have a way of
terminating a child thread safely and transfer control to the parent thread. RTSJ targets
this concern. It replaces the unsafe J ava mechanism for stopping threads.

7. Physical memory access:

Physical memory access is desirable for many applications that use RTSJ . RTSJ defines a
class that allows programmer to have a byte-level access to physical memory, also a class
that allows construction of objects in physical memory.

Sample Real time Java code:


In order to compile and run:
javacrt HelloRTWorld.java
javart HelloRTWorld


Implementation of RTSJ:

In March 2003 the first implementation of RTSJ is released by the TimeSys corp. J Time
is the industry's first commercial implementation of the RTSJ . J Time is completely
predictable response to J ava applications for real-time systems running on TimeSys
Linux.
TimeSys Linux provides an excellent platform for developing mission critical
applications for use in embedded computer systems that require completely predictable,
reliable response and execution under any circumstances. J Time Not only works with
TimeSys Linux, It also works with other Linux systems such as Redhat Linux.

Latest Application of JTime:

On J une 2003, NASA J PL lab and Sun Microsystems showed a J ava Mars Rover running
J Time on TimeSys' Linux. J PL and Sun are developing this rover for the next-generation
of Mars rovers that is going to be lunched in 2009. J PL is demonstrating the use of J ava-
based applications executed on a real-time Linux platform as an alternative to C/C++
applications on a traditional RTOS.







Conclusion:

J ava is trying to become real-time capable. We expect to see more complete and robust
implementations soon with increasingly popular embedded and real-time systems.




Sources:

1. JaRTS: A Portable Implementation of Real-Time Core Extensions for Java,
Urs Gleim, Siemens AG, Corporate Technology
2. Real-time Specification for Java (RTSJ) by Sione Palu
3. Golden Gate Project: RTSJ on a Mars Rover, Brian Giovannoni, Carnegie
Mellon University
4. The Real-Time for Java Expert Group (http://www.rtj.org)