The Source for Java Technology Collaboration
User: Password:



Janice J. Heiss

Janice J. Heiss's Blog

Gosling Goes Real-Time

Posted by hiheiss on May 23, 2006 at 03:55 PM | Comments (0)

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.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment



Only logged in users may post comments. Login Here.


Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds