RTGC related improvements in JavaRTS 2.2
The 2.2 release of JavaRTS just went life and this is a good opportunity to add an entry to my blog.
A lot of the features have already been described in the blogs that were written when the early access version became available. Check for instance Jim Connor's or Roland Westrelin's weblogs. Hence, I'll focus on memory management improvements.
Of course, the first point is that the Java Heap can now be bigger. With the 64-bit version, the size of the heap is now limited mostly by the physical memory available on your system. In addition, since the RTGC is fully concurrent, JavaRTS scales well: a bigger heap does not increase the pause times. Even if we have not yet seen a customer application impacted by fragmentation issues, a bigger heap offers an additional safety margin. The 64-bit drawback is that we do not yet support compressed oops. Hence, we suffer from the usual small throughput penalty due to the bigger size of the pointers. However, since the RTGC runs less often and recycles memory more efficiently when the Heap is very big compared to the live data, throughput can in fact improve for memory intensive applications.
The second point worth noting is the auto-tuner. We have worked with Sun Research Labs to improve the out-of-the-box soft real-time experience, optimizing the frequency of the RTGC cycles. The new auto-tuner is more precise. It also learns faster, improving the determinism for the first GC runs. Finally, it monitors the memory consumption and is able to better react to load changes. In fact, it will memorize information on the different loads and gradually learn how the application behaves. This should ensure that the RTGC is less likely to have to be boosted and disrupt the soft real-time threads. For more information, have a look at Sun labs technical report TR-2009-186.
For those familiar with the previous versions of the product, we have also reduced the number of CPUs used by default for the RTGC. It is still overestimated so that the auto-tuner should always be able to start the RTGC often enough to cope with the allocation rate. However, it no longer uses by default all the available CPUs. This allows even java.lang.Thread to benefit from our pauseless GC in the default configuration.
Finally, for the DTrace experts, we have slightly enhanced the RTGC related probes. This has been used for the "Tuning Memory Manager" part of a JavaOne 2009 talk I presented with Frederic Parain (our Thread Scheduling Visualizer expert): Easily Tuning Your Real-Time Application (TS-4807)
Bertrand.
