Java RTS 2.0 Update1 Released

Java RTS 2.0 Update-1 (90 days evaluation copy) is available for download. (Link: Download Java RTS)

The version available on Sun's site is for Solaris (both x86 & SPARC) only. IBM offers another version which runs on Linux with open-source real-time Linux extensions. There is no version available for Windows (with third party real-time extension). This update release provides support for Solaris 10 u4 and J2SE 5.0 u13 libraries as well as various security enhancements.

Java RTS features are delivered via a separate real-time enabled version of the Java VM. This VM can process both traditional Java SE components and Java RTS components. With Java RTS, real-time components and non-real-time components can coexist and share data on a single system.

This release is compliant with Real-Time Specification for Java (RTSJ). In fact, it is the first commercial implementation of RTSJ.

Here is more information on Java RTS (Taken from Sun's Document - as it is)

Here are the important features and benefits offered by the RTSJ and Sun's Java RTS implementation:

• New Real-Time Threads, Scheduling, and Synchronization

  The RTSJ introduces the concept of two new threads: real-time threads and no-heap real-time threads (a thread which cannot be interrupted by garbage collection). These threads offer more precise scheduling than with standard Java threads. They have 28 levels of priority and unlike standard Java, their priority is strictly enforced.

  Real-time threads are synchronized and are not subject to so-called priority inversion situations, where a lower priority thread has a block on a resource needed by a higher priority thread and thus prevents the higher priority thread from running. Rigorous testing with partners has shown that Java RTS completely avoids any priority inversions - which is crucial for mission-critical applications.

• New Memory Management Schemes

  The RTSJ defines two new types of memory areas that allow real-time applications to avoid unpredictable delays commonly caused by traditional garbage collectors:

  1. Immortal memory holds objects without destroying them except when the program ends. This means that objects created in immortal memory must be carefully allocated and managed.
  2. Scoped memory is used only while a process works within a particular section, or scope, of the program such as in a method. Objects are automatically destroyed when the process leaves the scope. This is a useful feature akin to garbage collection in that discrete creation and deletion is not required as in the immortal memory case - but the process must be sure to exit the scope to ensure memory is reaped.

  Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference.

• Asynchronous Events Handling & Asynchronous Transfer of Control

  The RTSJ provides two mechanisms for asynchronous communication: asynchronous event handling, and asynchronous transfer of control.

  Asynchronous event handlers deal with external events (known as "happenings") which can occur outside the JVM. The RTSJ is unique in that it allows developers to schedule the response to asynchronous events in order to avoid disrupting the temporal integrity of the rest of the real-time application.

  Asynchronous Transfer of Control (ATC) provides a carefully controlled way for one thread to interrupt another thread in a safe manner.

• Time & Timers

  The RTSJ specifies several ways to specify high-resolution (nanosecond accuracy) time including absolute time and relative time.

• Direct Access to Physical Memory

  While still maintaining security protections, the RTSJ allows direct access to physical memory. This means that device drivers can be created and written entirely in Java. Previously, Java applications had to link to native code to communicate directly with the hardware.

Java RTS Minimum Recommended System Requirements

• Dual core or dual CPU sytem with 512 MB
• Solaris 10 u3 SPARC or x86

What is a Real Time System (RTS)?

Real Time system does not mean a "fast" system. It means the system should respond to a worldly-event reliably and predictably. For example:

1. When an elevator reaches a floor, an event is generated. In response to this event, the system should stop the elevator immediately. If the system responds to this event late, the elevator would stop halfway. In this case, the timing is critical. If the system is very fast, but does not confirm to timing-contracts, it would not serve the purpose.
2. Another example is 'Anti-braking System (ABS)' in a car. When a wheel is locked, the system must respond to it by releasing it in timely manner. Any delay may have dangerous outcome.

A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. One of the definition (I found on Internet) is:

"A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred."

Most of the real-time systems are low level applications to control the physical hardware.

Hard and Soft Real Time System

In real time system, the time constraint is the one of the most important factor. In some applications, the time constraint is not flexible. Any minor deviation from the time constraint is considered as failure. This type of system is called Hard Real Time System. For example, a car engine control system is a hard real-time system because a delayed signal may cause engine failure or damage. Other examples of hard real-time embedded systems include medical systems such as heart pacemakers and industrial process controllers.

There are other scenarios where some latency is acceptable, which are called Soft Real Time System. Example: the software that maintains and updates the flight plans for commercial airliners. These can operate to a latency of seconds. Live audio-video systems are also usually soft real-time; violation of constraints results in degraded quality, but the system can continue to operate.

Components to implement a Real Time System

1. Operating System: The operating should support real time processing. It provides all the facilities to build a real-time application. It is a multi-tasking operating system and guarantees that the deadlines are met.
   
   VxWorks, QNX are few examples of operating system. Windows XP is not a real-time operating system. Through, there are few third party plug-ins, which are plugged into Windows XP to provide real-time facilities.
   
   If an application is developed & deployed on a real time operating system, it does not mean that the application is real-time. The application must be designed in a proper way to provide real-time behavior. It is similar to saying that everybody cannot drive the car. You need good training too for driving the car.
   
2. Application Framework: To create a new real-time system, the application development framework or environment should provide real-time facility too. For example: Java is not a real-time development environment. It has garbage collector, which can be initiated anytime to claim the free memory. When Garbage collection runs, it takes a lot of resources and other threads slow down. This delays in processing the event by other threads. This is one example where Java fails as real-time application development framework. Same is true for .NET too.
   
   Usually, C & C++ languages are usually used to develop real-time applications.
   
3. Application Design: The design of application should be such that it provides real-time functionality. If resources are available and design is not correct, you can't have a real-time solution.