RFR: 8297186: G1 triggers unnecessary full GCs when heap utilization is low [v5]
Thomas Schatzl
tschatzl at openjdk.org
Tue Dec 6 08:50:08 UTC 2022
On Tue, 6 Dec 2022 08:17:05 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
> Looks good.
>
> The change to `LotsOfClasses.java` is not obvious to me, did this change somehow alter the stability of that test?
The test loads lots of classes (30000+) which causes many Metaspace-sizing induced gcs. This can cause heap fragmentation at the end of the heap so that CDS fails to get a contiguous amount of memory for taking the CDS snapshot.
E.g. in the failure case the heap looks like this (after the full gc the CDS generation executes); using random region numbers.
Region 0-24: old
Region 25-470: uncommitted
Region 471-480: free
Region 481-504: old
Region 505-512: free
Now the CDS archive is larger than these 8 regions at the end, and CDS generation fails in like 50% of cases.
The reason why the block at 481-504 exists, is because gc compacts young gen formerly from ~481-512 into these regions as old, and due to other gcs (mixed phase/remark) happening before, due to it observing `MaxFreePercentage` option, it uncommits that huge block so that that CDS compacting full gc won't simply move that data to the very front of the heap (i.e. to region 25 onwards).
That MaxMetaspaceSize option greatly cuts down on these non-essential metaspace-induced gcs that mess up the heap to make the test fail.
-------------
PR: https://git.openjdk.org/jdk/pull/11209
More information about the hotspot-gc-dev
mailing list