Yesterday at Java One Sun finally announced the first implementation of JSR-1, the Real-time Specification for Java, since it was finalized in July of 2006. According to the JSR, the Real-time Specification is intended to support systems that "require strong deterministic guarantees and/or control in the areas of thread scheduling, synchronization overhead, lock queuing order, class initialization, maximum interrupt response latency, and GC characteristics."
Sun's implementation, dubbed the Sun Java Real-Time System (RTS) 2.0, will be made available to developers through regular OEM channels.
The Marketing
RTS 2.0 is Java 5 based and JSR 1 conforming, providing a robust real-time scheduling system. The centerpiece of the system is a real-time garbage collector that is highly configurable and very predictable. RTS is designed around Solaris 10, and will run on virtually any hardware platform supported by that operating system. (It won't be quite as effective on all of them, since some won't have the necessary hardware support for true real-time systems, but it will still provide greater control and predictability.) Support has already been integrated into NetBeans.
Contrast With WebLogic Real-Time: Me Too?
As Bill Roth alluded yesterday in his blog, two years ago BEA released a real-time system for Java, designed to minimize the impact of garbage collection on the performance of Java applications, and increase their predictability.The goal is to smooth performance out, limiting the interference caused by long garbage collections. Greg Bollella, Senior Staff Engineer for Real-Time Java at Sun, labels this a "low pause" approach to real-time GC. So why should we pay attention to RTS 2.0?
RTS 2.0 emphasizes the predictability of systems, in conformance with JSR 1. As covered previously on InfoQ, WebLogic Real-time provides < 30 millisecond latency, a dramatic improvement over the standard GC. Sun's interpretation of "Real-Time", though, translates to an implementation that provides assurance that interference from the GC will consistently be less than 200 microseconds, and with extra work allows the developer to escape the GC altogether for significantly more predictable execution.
The Developer's Perspective
So what does RTS 2.0 provide for the developer? In a nutshell: control over your systems.
The real-time garbage collector runs in a thread of its own, as has a priority assigned to it. When a developer creates a java.lang.RealtimeThread and assigns it a priority, that priority can be either higher or lower than the GC. If higher, that thread will only wait on the GC during certain critical sections in the garbage collection process. According to Greg, analysis has shown that these critical sections typically last no longer than 120 microseconds.
For systems that need even greater control, there is the more complex java.lang.NoHeapRuntimeThread (NHRT). An NHRT operates on its own private heap, outside the GC, and so doesn't wait on the GC under normal conditions. The only latency experienced by an NHRT is that imposed by the Solaris 10 dispatching system, which typically is in the 10s of microseconds.
The key to good real-time programming is still in design. The RealtimeThread relies heavily on the command-line parameters used to tune the real-time garbage collector, since improper tuning can result in threads waiting on the GC to free memory. The NHRT involves significant complexity, since the java developer must learn to manage the private heap. (Communication between NHRTs and objects on the regular heap is also complicated.)
What's Next?
Greg Bollella provided some insight into the future of Real-Time Java. RTS 2.1 may include tools to assist the developer in tuning the all-important command line parameters governing the real-time GC, as well as useful scripts and guides. It will also likely add support for "ergonomic" tuning of the GC. And RTS 2.0 does not support the extended features of JSR 282, or address the safety critical requirements of JSR 302, which provides ample opportunity for enhancement.
Sun's implementation, dubbed the Sun Java Real-Time System (RTS) 2.0, will be made available to developers through regular OEM channels.
The Marketing
RTS 2.0 is Java 5 based and JSR 1 conforming, providing a robust real-time scheduling system. The centerpiece of the system is a real-time garbage collector that is highly configurable and very predictable. RTS is designed around Solaris 10, and will run on virtually any hardware platform supported by that operating system. (It won't be quite as effective on all of them, since some won't have the necessary hardware support for true real-time systems, but it will still provide greater control and predictability.) Support has already been integrated into NetBeans.
Contrast With WebLogic Real-Time: Me Too?
As Bill Roth alluded yesterday in his blog, two years ago BEA released a real-time system for Java, designed to minimize the impact of garbage collection on the performance of Java applications, and increase their predictability.The goal is to smooth performance out, limiting the interference caused by long garbage collections. Greg Bollella, Senior Staff Engineer for Real-Time Java at Sun, labels this a "low pause" approach to real-time GC. So why should we pay attention to RTS 2.0?
RTS 2.0 emphasizes the predictability of systems, in conformance with JSR 1. As covered previously on InfoQ, WebLogic Real-time provides < 30 millisecond latency, a dramatic improvement over the standard GC. Sun's interpretation of "Real-Time", though, translates to an implementation that provides assurance that interference from the GC will consistently be less than 200 microseconds, and with extra work allows the developer to escape the GC altogether for significantly more predictable execution.
The Developer's Perspective
So what does RTS 2.0 provide for the developer? In a nutshell: control over your systems.
The real-time garbage collector runs in a thread of its own, as has a priority assigned to it. When a developer creates a java.lang.RealtimeThread and assigns it a priority, that priority can be either higher or lower than the GC. If higher, that thread will only wait on the GC during certain critical sections in the garbage collection process. According to Greg, analysis has shown that these critical sections typically last no longer than 120 microseconds.
For systems that need even greater control, there is the more complex java.lang.NoHeapRuntimeThread (NHRT). An NHRT operates on its own private heap, outside the GC, and so doesn't wait on the GC under normal conditions. The only latency experienced by an NHRT is that imposed by the Solaris 10 dispatching system, which typically is in the 10s of microseconds.
The key to good real-time programming is still in design. The RealtimeThread relies heavily on the command-line parameters used to tune the real-time garbage collector, since improper tuning can result in threads waiting on the GC to free memory. The NHRT involves significant complexity, since the java developer must learn to manage the private heap. (Communication between NHRTs and objects on the regular heap is also complicated.)
What's Next?
Greg Bollella provided some insight into the future of Real-Time Java. RTS 2.1 may include tools to assist the developer in tuning the all-important command line parameters governing the real-time GC, as well as useful scripts and guides. It will also likely add support for "ergonomic" tuning of the GC. And RTS 2.0 does not support the extended features of JSR 282, or address the safety critical requirements of JSR 302, which provides ample opportunity for enhancement.