<div dir="ltr"><div>Hi,<br></div><div><div><br></div><div>We (Java platform team at Google) are comparing G1's performance in JDK9u and JDK10. We expect JDK10's G1 to perform better because of <a href="http://openjdk.java.net/jeps/307">JEP 307 (Parallel Full GC)</a>.</div><div>However, we found a performance regression in JDK10 with DaCapo benchmarks. We set the heap size small (about 2-4 times of minimum heap) so they trigger interesting GC activities.</div><div><br></div><div>We found JDK10's full GC results in significantly more wasted space in Old regions, which leads to a more fragmented heap and fewer Eden regions. We also found the amount of wasted space after a full GC is proportional to the number of ParallelGCThread. As a result, several benchmarks trigger more Young, Mixed and concurrent collections, leading to increased CPU usage and pause time. One reason that makes these benchmarks sensitive to full GC is that DaCapo harness performs a System.gc() in-between each iteration of the benchmarks. So a more fragmented heap hurts the benchmark from the beginning of every iteration.</div><div><br></div><div>We are aware this is probably a known issue as described in <a href="http://openjdk.java.net/jeps/307">JEP 307:</a></div><div>"Risks and Assumptions: The fact that G1 uses regions will most likely lead to more wasted space after a parallel full GC than for a single threaded one."</div><div>However, it is not impossible to optimize the full GC to reduce wasted space. After all, a stop-the-world parallel mark-sweep-compact algorithm should be able to efficiently compact the heap.</div><div><br></div><div>We did not find any RFE or discussion on JBS regarding this. Is there any ongoing effort to reduce wasted space in parallel full GC?</div></div><div><br clear="all"><div><div class="gmail-m_7796762574312507106gmail_signature"><div dir="ltr">-Man</div></div></div>
</div></div>