The normal RTGC thread priority is above that of non-real-time threads (JLTs), but at the lowest priority for real-time threads. When the Java RTS JVM decides that memory is getting low, the RTGC critical priority is boosted to higher than the priority of the non-critical threads, but still lower than that of the critical threads. In effect, the RTGC steals time from non-critical threads to ensure that critical threads always have the memory they need. As a last resort, if the priority boost fails to secure enough memory for critical threads, the RTGC will actually stop allocation in non-critical threads, effectively halting them until critical thread memory demand is satisfied.

The RTGC runs fully concurrent with application threads, and thus can be preempted at any time. There is no need to run the RTGC at the highest priority, and there are no stop-the-world application thread pauses. On a multiprocessor, one CPU can be doing some GC work while an application thread is making progress on another CPU.

Therefore, the RTGC is very flexible. While other real-time GCs must be executed as incremental, periodic, and high-priority activities (or else induce an allocation-time overhead), the Java RTS RTGC can execute according to many different scheduling policies.

Instead of trying to ensure determinism for all the threads of the application, the RTGC ensures hard real-time behavior for critical real-time threads only while offering soft real-time behavior for threads below the critical level. Total RTGC overhead is thus reduced and critical thread determinism is not impacted by the addition of new low-priority application threads. In addition, configuration is easier because there is no need to study the allocation behavior of an application in its entirety in order to configure the RTGC. You must consider only the behavior of critical tasks when designing the system. It’s unnecessary to reconfigure the RTGC when you add a new non-critical component or when the machine load changes.

The RTGC tries to recycle memory quickly enough for the non-critical real-time threads, but without offering any guarantees for them. If the non-critical load increases, the RTGC might fail to recycle memory fast enough to satisfy all threads’ allocation demand. Critical threads will not, however, be disrupted as long as enough memory is reserved to service them. Only non-critical real-time threads will be blocked and temporarily suffer jitter. The amount of memory to reserve is a key parameter that must be set by a programmer.

Finally, the RTGC has an auto-tuning mechanism that tries to find the best balance between determinism and throughput. Expert users can configure the auto-tuning system in order to improve that balance.

Conclusion
Real-time systems such as Java RTS and non-real-time systems such as Java SE can be configured to produce more or less degrees of predictability. True determinism can be obtained only from systems that bound jitter, which only a true real-time virtual machine can do.

If your application can tolerate some degree of non-determinism, then use a non-real-time virtual machine and tune it to obtain the response time you need, down to perhaps a 20 millisecond latency or so, but be aware that there will be occasional response time outliers. If you need response times below 20 milliseconds, even down to 30–70 microseconds, use Java RTS and its RTGC.

Achieving any degree of predictability requires trading off application throughput in various ways. Virtual machine selection and configuration therefore occurs along a predictability spectrum. As virtual machines evolve, we can expect to be able to specify a desired level of predictability and have the system configure itself automatically to achieve it. Until then, a degree of manual configuration will be necessary. Using Java RTS and RTGC minimizes the effort necessary to achieve sub-millisecond levels of predictability.

References

• Real-Time Specification for Java
  
• Sun Developer Network: Sun Java Real-Time System
• Java SE Performance Page