Java’s G1 garbage collector would benefit from greater throughput and reduced CPU usage through a plan being floated in the OpenJDK community.
A draft JDK Enhancement Proposal (JEP) titled, “Throughput post-write barrier for G1,” would have the collector use a throughput-optimized barrier when concurrent refinement has been disabled to achieve better throughput at the cost of latency on certain workloads that are not latency-sensitive.
The plan would be implemented through a new JVM flag, -XX:-G1UseConcRefinement, which would turn off concurrent refinement and allow G1 to use a “throughput post-write barrier.” G1UseConcRefinement would be enabled by default, while the use of -XX:-G1UseConcRefinement would boost G1’s throughput and cut CPU usage, according to the proposal. The simplified write barrier would be much shorter in length, improving the cache hit rate. This mode would cut the workload for handling a dirty card and compilation work for JIT compilers. Further, the mode would reduce memory footprint by shrinking remembered sets and not using per-thread dirty card queues.
G1 currently has a more complex post-reference write barrier than write barriers for more traditional collectors such as the Concurrent Mark Sweep collector. This complexity is largely due to support for concurrent refinement, which moves some scanning work in the collection pause to work being done concurrently to the application. The refinement mechanism incurs noticeable overhead during execution.
The proposal would not let the Java Virtual Machine determine when to disable concurrent refinement and optimize barriers. Nor would the proposal limit the availability of other G1 features such as string deduplication when concurrent refinement is disabled.