Posted by hiheiss
on May 23, 2006 at 3:55 PM PDT
At the JavaOne Conference Friday morning keynote, 5/19/06, James Gosling talked with Sun Distinguished Engineer Greg Bollella about Real-Time Specification for Java (RTSJ).
At the Friday morning keynote, 5/19/06, James Gosling talked with Sun Distinguished Engineer Greg Bollella about Real-Time Specification for Java (RTSJ). â€œGreg was the original spec lead for JSR 1 where I was one of the worker bees,â€ remarked Gosling. The big news is that Sun Java Real-Time System 2.0 is in the pipeline and supports new platforms â€“ in particular real-time garbage collection.
Bollella launched into an explanation of real-time garbage collection. â€œThe idea of real-time GC is straightforward,â€ explained Bollella. â€œYou want the application and the garbage collector to be able to communicate so as to intelligently allocate
resources so some set of threads that can make forward progress without being impeded by the GC.â€
Supposedly, the best real-time GC was created by a team at a Swedish university. â€œWe like this GC,â€ said Bollella. â€œIt really embraces the real-time scheduling notion that we put in RTSJ. The idea is that GC has a priority that is manipulable by the application and it can set the GC priority anywhere in the range of the number of threads. In our case, itâ€™s 60 priorities. All of the threads with priorities higher than the garbage collector preempt the collector, so the only
interference you get is normal thread switch time, plus a little bit of critical section from the GC.â€
Gosling pointed out that what Bollella had described sounded pretty obvious, but â€œfor any of you who have mucked around with garbage collectors, you know that the GC needs a stable picture of whatâ€™s going on in memory. If there is stuff running asynchronously, all hell breaks loose.â€
Bollella responded that the read and write barriers for real-time GC are obviously more complex and such barriers have costs. The solution is to analyze the high priority threads and make sure the
GC gets enough cycles to produce enough free memory so they can run unimpeded.
Bollella then explained how the collector works.
â€œAny of the threads can allocate in area A. But only the higher priority threads can allocate in areas B and C. If you arrange things just right, while those high priority threads are using free memory in C, the garbage collector comes behind the scenes and cleans up
the area in B. It can flip-flop back and forth between B and C like that forever.â€
Gosling characterized the GC as more of a â€œfocus of attention collectorâ€ than a â€œcopy collectorâ€.
â€œExactly,â€ replied Bollella. â€œOf course, you can arrange the system so that they flop back and forth between B and C and the threads with lower priority never get any CPS cycle -- you have to think about that as well. That will be in the next release of Java RTS.â€
Bollella concluded with a brief account and demo of how, with relatively little tweaking, his team effectively turned a Sun Java System Application Server into a real-time application server.
Here's an interview I did with Sun's Greg Bollella on Real-Time Specification for Java.