-
Bug
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14
-
b17
There is a problem with current Full GC that can be seen in the tests that make lots of humongous fragmentation, and rely on Full GC to fix that up, for example tools/jlink/JLinkTest:
$ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jlink/JLinkTest.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=passive"
...
Error: Java heap space
java.lang.OutOfMemoryError: Java heap space
at java.base/java.io.InputStream.readNBytes(InputStream.java:442)
at java.base/java.io.InputStream.readAllBytes(InputStream.java:346)
The underlying cause is that when Full GC figures out the next region for compaction, it ignores empty regions. Which means it only compacts "within" the subset of allocated regions, which does not help external fragmentation. The next humongous allocation has a chance to fail.
The way out is to consider empty regions for inclusion into sliding slices when Full GC code looks for the next candidate.
$ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jlink/JLinkTest.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=passive"
...
Error: Java heap space
java.lang.OutOfMemoryError: Java heap space
at java.base/java.io.InputStream.readNBytes(InputStream.java:442)
at java.base/java.io.InputStream.readAllBytes(InputStream.java:346)
The underlying cause is that when Full GC figures out the next region for compaction, it ignores empty regions. Which means it only compacts "within" the subset of allocated regions, which does not help external fragmentation. The next humongous allocation has a chance to fail.
The way out is to consider empty regions for inclusion into sliding slices when Full GC code looks for the next candidate.