|By Janice J. Heiss, April 6, 2006|
It's conventional wisdom that real-time programming is challenging. But this has changed under the leadership of Sun Microsystems Distinguished Engineer, Greg Bollella. Real-Time Specification for Java (RTSJ) has taken a highly-engineered and optimized system platform, the HotSpot JVM, and modified it so that it not only retains its value for non-real-time programs, but can engage in real-time programming of physical systems with relative ease.
Greg Bollella formerly worked at IBM, where he led the Real-Time for Java Expert Group under the Java Community Process (JCP), which developed RTSJ. In 2000, he joined Sun Microsystems Laboratories and is now the Distinguished Engineer for the Real-Time Java group. He has a Ph.D. in computer science from the University of North Carolina at Chapel Hill, where he wrote a dissertation on real-time scheduling theory and real-time systems implementation.
We met with him to get an update on recent developments in RTSJ, along with the Sun Java Real-Time System, the first conformant commercial implementation of Java Specification Request (JSR) 1.
What are the basic problems RTSJ attempts to solve?
Whenever computers control physical devices in the world, a control system is required that usually has three interacting parts -- sensing, control, and actuation. "Sensing" means there are sensors in the environment that measure physical quantities -- temperature, pressure, humidity, force, and so forth. "Control" takes the values from those sensors, and creates an output command for what's called an actuator. "Actuators" are things that physically impact the environment. Control systems with sensors, control mechanisms, and actuators are everywhere. We see them in trains, planes, automobiles, traffic lights, financial trading systems (believe it or not these trading engines can really be modeled just as a physical control system), chip fabrication machines, and so on.
If you're going to control something, you must make sure that the time between sensing and command is limited by some maximum amount. For example, you can't download something from the web when trying to control something else because what you are trying to control will then fail. It's a fundamentally different system from what we are used to today.
The problem is that general-purpose computing success -- such as the web and business computing transactions and performance -- is measured by speed. In the control space, when you have to manipulate physical devices, just being fast enough isn't good enough, because you also have to be predictable. And that's not so easy to do in general-purpose machines.
The Sun Java Real-Time System (Java RTS)
The Sun Java Real-Time System is the first conformant commercial implementation of Java Specification Request (JSR) 1, the Real-Time Specification for Java (RTSJ). Java RTS enables developers of real-time applications to take full advantage of the Java language ecosystem while maintaining the predictability of current real-time development platforms. This means that real-time components and non-real-time components can coexist and share data on a single system.
Java RTS also brings the world of real-time programming to developers currently using Java technology to create applications that involve the physical world. For either audience, Java RTS offers a very predictable, low-latency, modern software architecture that can bring the core benefits of Java technology to developers whose applications interact with the physical world.
Java RTS 1.0 has shipped (Solaris 10 SPARC only), and Java RTS 2.0 is currently under development.
What are the most important innovations in RTSJ? And is it as challenging as some people claim?
People tend to focus on the scope memory, immortal memory, and NoHeapRealtimeThread, but there's also innovation in the use of real-time garbage collection, which is another complete subsystem of the RTSJ that also can give you very good predictability -- much more than the typical Java programmer is used to, with pause times in the few millisecond range. This is becoming important because many customers think real-time garbage collection is a good idea.
The RTSJ has three execution contexts for developers to use. These give varying amounts of predictability and performance and are roughly defined by three thread types, java.lang,Thread, javax.realtime.RealtimeThread (RTT), and javax.realtime.NoHeapRealtimeThread (NHRT). RTT's need a real-time GC to get predictability. NHRTs get predictability by using memory other than the regular Java heap (such as immortal and scoped memory). NHRTs give the best predictability (measured by a metric commonly referred to as 'maximum latency').
The developer's use of scoped memory and no heap threads is a more difficult programming model than the common Java programming model. It's not more difficult than the typical real-time model. With RTSJ, you have to pay explicit attention to memory consumption and object creation in a particular memory area so that you don't get exceptions.
"Real-time programming is challenging, but we're making it easier."
Distinguished Engineer at Sun Microsystems
So real-time programming is challenging, but we're making it easier. Using scoped memory in NHRT makes it easier for a real-time programmer migrating from C or C++ to RTSJ.
Tell us how you are making it easier.
If a Java programmer wants to write code that's somewhat more predictable than they're used to writing, but not down to the microsecond latency range, the programming model for RTSJ is very simple. In fact, you only have to make one small change -- instead of writing
java.lang.Thread you just have to write,
javax.realtime.RealtimeThread. With that one change, you get industrial strength real-time garbage collection. You get priority inversion avoidance, and you get strict, precise, and correct priority dispatching semantics. These features go a long way towards producing code that behaves better with respect to time.
To get predictability out of a real-time garbage collector, you have to know something about how your program demands memory from the heap, because the garbage collector and the program are both using the heap. The program is making garbage. The garbage collector is turning garbage into free memory, and they have to interact in the heap. And they can't do that at the same time. There has to be some "synchronization" between the two. So, you have to tell the garbage collector something about how fast your program is going to create garbage so that it knows how fast it has to clean it up. Getting that number can be somewhat tricky. But you have to think about memory, no matter what you do.
"We're trying to make it possible for people to use RTSJ implementations quickly and easily, and not worry so much about scoped memory and the more intricate details."
Distinguished Engineer at Sun Microsystems
We're trying to make it possible for people to use RTSJ implementations quickly and easily, and not worry so much about scoped memory and the more intricate details. We encourage people to try the real-time garbage collection first, and as they gain experience, we provide tools to help them analyze the memory behavior of their program so that they can refine how they ask the garbage collector to produce the free memory, which may be all they need.
If it's not enough and their pauses are still too much, or they can't really understand their program well, and get some unpredictable pauses from the garbage collector, then they might have to recode parts of it using NHRTs and scoped memory. But, most likely this will be only the simple lower-level control loop.
What other technical challenges and innovations should developers understand about RTSJ?
Getting predictability requires trade-offs. Typically what you give up is average throughput performance. There's not much we can do about that. We try to minimize the through-put costs in various implementations that are available, but "there is no free lunch".
Could you explain RTSJ's innovations in application logic as it relates to asynchronous events?
In the past, the application logic handled truly asynchronous events from outside the application process domain through the processor interrupting the application logic, taking care of the asynchronous issue on its own, beneath the level of visibility of any scheduling or dispatching mechanism. The programmer wrote code that they expected to execute and complete in a certain amount of time, but it would take longer than they thought. The processor was intermittently busy handling asynchronous functions like interrupt handlers or signals. The RTSJ includes a mechanism that removes the invisibility attribute of these asynchronous activities and brings them into the visibility of the scheduling and dispatching mechanism. They no longer cause the system to steal CPU cycles from the application logic, but they're a first-class citizen in the scheduling system of the RTSJ. So they get appropriate cycles when they should get them.
Tell us about the 2006 JavaOne Conference Slot Car Programming Challenge.
For the 2006 JavaOne Conference, we're creating a Slot Car Programming Challenge with small 1/24 scale cars with electric motors that move around on a track. Normally, these cars are driven through a small handheld controller that you push down to send voltage to the car to make it go faster, and lift up to slow it down. You drive it around a complex track. The challenge is to make it around the track as fast as possible without going so fast around the corners that you wipe out. The trick is to go fast on the straightaways, and slow down enough not to spin out on the corners.
At the Conference, we are going to install about 100-200 feet of track and embed the track with 200 sensors. The program can detect whether or not the car is over a sensor, but it can't tell which sensor. All the sensors will be merged together. Developers who enter the Challenge have to write a polling loop that gathers the sensor data and continually monitors whether the car is over a sensor.
Then the program gives the car the appropriate voltage so that it goes fast on the straight-aways and slow on the curves. Contestants will write the code in the labs and bring it to the track where we run it on a machine. We'll be keeping time as the car goes from the start to finish line. The 10 best times at the end of the Conference all get prizes.
Here are some tips: create an NHRT that loops maybe every five milliseconds or so and reads the sensor data. If you do that, you are certain to pick up all the sensors, because you won't have any delays. If you use a real-time thread or a Java thread to do that, when the garbage collector hits, the thread's going to be paused, and the car may drive over a sensor. Then you'll be confused as to which sensor you're over, and give it the wrong voltage, and you're either going to go too slow on the straightaway, which will increase your time, or too fast on a curve, and you'll wipe out and spin off.
We'll set it up so developers will use a framework that includes a couple of threads that gratuitously create garbage so that they have to get the right answer.
Could you clarify what "real-time" means?
"Scientifically speaking, real-time means 'the ability to reliably and predictably reason about and control the temporal behavior of program logic'"
Distinguished Engineer at Sun Microsystems
People confuse "real-time" with "real fast" because to them, real-time is equivalent to real fast. Scientifically speaking, real-time means 'the ability to reliably and predictably reason about and control the temporal behavior of program logic'. The computer will respond all of the time before some particular deadline that you've given it. It's predictable. Depending on how you set your deadlines, numerous systems could be called real-time. For instance, say, you program a computer to display a character on the screen when you type a character on the keyboard, and your deadline is six days from now. But, as you abbreviate that deadline more and more and get into the millisecond range, then things start to get interesting.
Take the slot cars. Reading the sensor register is a very simple operation that takes very little CPU horsepower. It can be done on a very slow machine. But, if something within the system causes your application to be delayed (something over which you have no control) you've got problems. A particular piece of code must always complete its scheduled activity before a relatively short deadline, such as five milliseconds. Having a computer do something fast or with high throughput, and having it do something predictably, are quite different.
Are there any issues about non-real-time Java programs executing on the RTSJ implementation?
No. Everything we've tested runs fine, though slightly slower.
What opportunities exist for developers in RTSJ?
Many customers who use Java technology to write large web services applications to run on application servers want more predictability in their code execution. Real-Time Java allows them to use the real-time garbage collection feature to get more predictability in their execution of the application server.
There is a demand for real-time developers in the Java EE world, especially where RTSJ can be used in bigger applications to make them more predictable. Likewise, in the Java SE world, many embedded devices are now so big and powerful they can run Java SE right out of the box. We're getting requests from makers of embedded devices who want more predictability.
I wouldn't say that a Java developer can jump right in and start writing telecommunications infrastructure node code. They'll need some training.
The major industries where RTSJ has potential are government, defense, telco, financial, industrial, and automation. And the Sun Java Real-Time System is being used by the Navy, Raytheon, and Boeing.
What has prevented Java technology and the other garbage collection languages from being widely used in real-time industries?
The entire class of garbage collection languages has been perceived to be too unpredictable and to demand too many resources from the computing device. What's changing is that people in the real-time space are finding that the code that they have to write is getting so large and so complex that they really need the power of an object-oriented, automatically garbage collected language. So, they're starting to turn to Java technology in these areas.
What advantages does Java technology offer in running real-time systems compared to other languages?
All the advantages of the Java language. The user community is large; there are a lot of tools; and the platform is well supported. You can get help anywhere on the web. Google "Java exception" and you'll get many results.
What is the greatest FUD associated with Java and real-time?
"The Slot Car Challenge at the 2006 JavaOne Conference will prove that anyone can program with RTSJ."
Distinguished Engineer at Sun Microsystems
That it's hard to program. It's really simple to program when starting out. Sure, it can get quite complex, but, initially, using it is simple. The Slot Car Challenge at the 2006 JavaOne Conference will prove that anyone can program with RTSJ. If a developer gets the car to go around the track without missing any of the sensors, they will have written hard real-time code in the most rigorous sense of hard real-time. And they will have done it, in all likelihood, never having written hard real-time code in their life.
"I want to get the message across to the developer community: Real-time Java isn't rocket science. It's more like bicycle science."
Distinguished Engineer at Sun Microsystems
I want to get the message across to the developer community: Real-time Java isn't rocket science. It's more like bicycle science.
What is distinctive about the Sun Java Real-Time System?
The Sun Real-time Java is the only compliant JSR-1 implementation on the market today. JSR-1 requires you to pass one of the four TCKs (technology compatibility kits) in the JCP -- that's Java EE, Java SE, Connected Device Configuration (CDC), or Connected Limited Device Configuration (CLDC). So, unless a JSR-1 implementation passes one of those, as well as the JSR-1 TCK, it can't be called compliant. We believe that if a large company such as a telco is going to invest hundreds of millions of dollars into writing new programs for the infrastructure, they're going to want to do it on compliant systems. If other implementations of JSR-1 become compliant, and can be used in lieu of ours, then our customers can pick and choose the implementation based on whatever they think is appropriate for their business.
Any final message for developers on RTSJ?
Start using RTSJ and see how simple it is. Get an edge up in many industries because for a large number of applications, it's becoming a required skill.
And, finally, please come to the 2006 JavaOne Conference and enter into the Slot Car Challenge.