Interviews from JavaOne 2007

In most Java VM implementations, the garbage collector has the right to stop a thread in order to reclaim memory no longer used by that thread. Such garbage-collection pauses are the main reason threads running in a regular JVM cannot guarantee the exact timing of their execution.

Garbage-collection pauses are not acceptable in applications with real-time requirements, and in this installment of Artima's JavaOne 2007 interview with Greg Bollella, Sun's lead engineer of Real-Time Java, and Dave Hofert, the company's Real-Time Java marketing manager, the two focus on a new feature of Sun's real-time JVM implementation: the real-time garbage collector, RT GC.

Bollella explains that,

Real-time garbage collection is a powerful technique [that] allows people to write very predictable code but still in the complete Java programming model where the garbage is collected automatically... Real-time GC is a first-class thread in the VM, and you manipulate its behavior just as you'd [manipulate] any other thread's.

Bollella notes that real-time GC takes advantage of periodic pauses in execution, a common characteristic of real-time applications:

In our world, a lot of processes are periodic. They execute at a constant frequency. They will execute every millisecond, and they will do a little bit of work every millisecond. In control, that's the norm. If you're controlling a robot... every millisecond we send commands to the robot. Trading applications are not periodic, but ... you can characterize their behavior [in a way] that they get busy for a while, and then they don't get busy.

Real-time threads are allocated a special area of the heap, and the real-time GC itself is a thread whose priority can be scheduled in relation to other real-time threads. Instead of interrupting a real-time thread to reclaim memory, the real-time GC takes advantage of application pauses to do its job when a real-time thread reaches a high watermark set by the developer for that thread:

We give the developer the ability to tell the GC some things about the program behavior, specifically about the memory consumption of a certain small set of threads... The GC can [then] arrange that it collects garbage when the application isn't running... The collector is never forced to stop the application.

In the current release of Sun's Real-Time JVM, a developer must explicitly specify that high watermark value for a real-time thread. In future releases, however, the GC will be able to use program heuristics to deduce some of that information:

In our update release... we're looking at heuristics for the RT GC so that to some extent we will be able to allow the RT GC to configure itself. In the ... soft real-time world, we can allow the real-time GC to change its behavior based on looking at how the memory is being allocated.

In contrast to real-time threads, no-heap real-time threads (NHRT) don't ever get garbage collected:

NH RT is another thread type ... that is a much more rigorous thread that never undergoes garbage collection. The objects it uses are permanent, they stay there forever... You can interrupt anything in the system, right down to the ... OS. So you get latency numbers in the order of 20 microseconds.

Greg Bollella, Senior Staff Engineer, and Dave Hofert, manager of Java Embedded and Real-Time Marketing, both with Sun Microsystems, talk about real-time garbage collection. (7:00 minutes)

What do you think of Bollella and Hofert's comments on real-time GC?

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the authors

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.