One of the oldest JSRs is about a real-time extension for the Java platform. But are real-time requirements compatible with the Java religion?

In "Real-Time Java: An Introduction," Peter Mikhalenko discusses the obstacles and advantages to real-time Java.

Real-time Java offers a much more reliable and predictable scheduling mechanism, memory handling methods, different memory models, a more predictable threading and synchronization model, asynchronous event handling, and high-resolution time handling. It makes predictable execution the first priority in all trade-off decisions, sometimes at the expense of typical general-purpose computing performance measures.

Mikhalenko also discusses some issues that must first be addressed before deploying real-time Java, among them GC semantics, synchronization, thread scheduling and high-resolution time management.

Real-time application development requires an API set and semantics that allow developers to correctly control the temporal behavior of application, i.e., how it will behave in real-world time. A real-time edition of Java must therefore provide some semantic JVM enhancements and a new API set appropriate for real-time applications. It is not surprising that the main obstacle in achieving real-time characteristics for Java is its garbage collector. A real-time garbage collector became a revolutionary and central component of Sun's recently-released Java real-time edition RTS 1.0, although its first implementation does not include one (it is expected in the next release). Java RTS addresses other issues, making strong deterministic guarantees for thread scheduling, synchronization overhead, lock queuing order, class initialization, and maximum interrupt response latency. Java RTS is intended only for suitable underlying operating systems, which means that only a real-time operating system, such as QNX, is appropriate for implementing the JVM.

Mikhalenko goes on to explore some of the new features of Sun Java RTS 1.0, including:

• Direct memory access
• Asynchronous communications
• Memory management
• Real-time threads

He also takes a look at how easily a programmer can use the new real-time Java features, where threads and memory are concerned.

Do you think real-time Java programming has an effect on the enterprise programmer? Why or why not?

What do you gain by writing a real time system in Java as opposed to C++? It's a genuine question ..

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

It is, and I think the answer is the same as the thinking that goes behind almost any Java project to this day.

It is a lot easier (& faster to develop in) than C++, and can can be more portable.

Can arguably be safer as well since Java is less prone to some of the really hard to find C++ bugs (like memory leaks -- and note that I said less prone, not immune).

That said, I'm not sure Java is the right tool for the real time job either.

It seems like the type of application where mucking around in the low-level hardware-specific details is very
important. Which is something C/C++ lends itself to, while Java does not.

Of course I've never programmed a real time application, so I am mostly wildly guessing.

Of course I've never programmed a real time application, so I am mostly wildly guessing.

I did. Your text is accurate.

What do you gain by writing a real time system in Java as opposed to C++? It's a genuine question ..GuglielmoEnjoy the Fastest Known Reliable Multicast Protocol with Total Ordering.. or the World's First Pure-Java Terminal Driver

The author of the article points out that implementing a real-time garbage collector is one of the largest challenges of implementing real-time java.

This can be generalized - implementing a real-time memory management system is one of the central challenges to implementing a real-time system.

I think for realtime systems with adequate CPU and memory resources having a garbage collector would be a godsend.

New/delete/malloc/free are far from real-time operations in their normal incarnations. They're potentially as subject to pauses as a good GC. Furthermore, they're much more subject to heap fragmentation the JVM style GC, because the JVM can moves things around in physical memory (compact the heap) because application code doesn't have references to physical locations.

I'm not saying a programmer can't come up with something more efficient in C/C++, especially if he sticks to stack allocation. But it's more difficult.

I think Java will allow real-time programmers to program in a more natural way. But I haven't done much realtime development, so take what I say with a grain of salt.

One of the most exciting parts of a C/C++ real-time project is debugging mystery crashes. Using Java would prevent those pesky hard to debug crashes because programmers couldn't scribble over other peoples memory or reuse delete objects or most of the other things you can do to shoot yourself.

"Do you think real-time Java programming has an effect on the enterprise programmer?"

Something I've often come across doing heavy duty enterprise development is that performance can often become unpredictable when the garbage collector cuts in. Although this can be indicative of poor code (too many short lived objects going on the heap etc.) and you can work around it with the bigger App Servers by using load balancing across multiple smaller JVM's for instance, faster and more predicable garbage collection, a fundamental requirement for the real-time stuff, would be very helpful. So I do think the work Gossling and others have been doing in this area does have relevance to the JEE world.
  

Charles
Twofish music -
  Intelliget Ambiant Techno

Something I've often come across doing heavy duty enterprise development is that performance can often become unpredictable when the garbage collector cuts in. Although this can be indicative of poor code (too many short lived objects going on the heap etc.) and you can work around it with the bigger App Servers by using load balancing across multiple smaller JVM's for instance, faster and more predicable garbage collection, a fundamental requirement for the real-time stuff, would be very helpful.

This is a slightly different problem from what RTSJ aims to solve, and one that the BEA JRockit team has been working for some time now. Our view is that programmers that are looking for low latencis (i.e. not necessarily hard real-time) shouldn't have to make (m)any changes to their Java code to get this. Instead we have developed a feature we call the "Deterministic GC", which is available as part of the WebLogic Real Time product. For more information:

Introduction to WebLogic Real Time
Performance article

These are still fairly high-level, I'm afraid. There is a more technical white paper coming out soon, and it will be covered in several BEA sessions at JavaOne next week. Or go to the BEA booth and ask my JRockit colleagues for the nitty-gritty details.

Henrik Ståhl
Product Manager, BEA JRockit