Oracle proposes G1 as the default Garbage Collector for Java 9
The new proposition to make G1 the star of the garbage collecting show has started to gather speed and there’s a decent amount of Java heads not happy about it. If your app has a small footprint, perhaps you’ll be worse off.
Oracle has begun considering JEP 248 of the JDK Enhancement Proposal for the likes of Java 9, which would make Garbage-First (G1) its standard garbage collector. The decision has caused quite a stir in the Java community, with many deeming the Concurrent Mark Sweep (CMS) Collector as more than sufficient.
Previously, the standard garbage collector for server configurations was the ParallelOld, which aimed to maximise application throughput by occasional stop-the-world (STW) pauses. This is particularly suitable for applications where the response time is irrelevant (e.g. batch processing).
The G1 Collector contrast minimises STW pauses, for which a heavier burden is taken into account. This works particularly well for low-latency applications such as web servers. Oracle themselves agree with this sentiment, with the CMS collector filling the same role in HotSpot, hence the community controversy:
The concurrent collector is designed for applications that prefer shorter garbage collection pauses and that can afford to share processor resources with the garbage collector while the application is running.
Numerous benchmarks clearly indicate that the CMS option is better in applications with a relatively small footprint than the G1 collector, which is also reflected in the official description:
The first focus of G1 is to provide a solution for users running applications that require large heaps with limited GC latency. This means heap sizes of around 6GB or larger, and stable and predictable pause time below 0.5 seconds.
The G1 collector is fully supported in Oracle JDK 7, update 4 and later releases. Applications running with either CMS or ParallelOld are recommended to switch to G1 if their application has one or more of the following traits:
- More than 50% of the Java heap is occupied with live data.
- The rate of object allocation rate or promotion varies significantly.
- Undesired long garbage collection or compaction pauses (longer than 0.5 to 1 second)
Further feedback and comments are welcomed via OpenJDK and the [email protected] mailing list.