JDK-8245925 : G1 allocates EDEN region after CDS has executed GC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12,13,14,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-05-27
  • Updated: 2024-10-16
  • Resolved: 2020-06-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b02Fixed
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Description
During the development for JDK-8244778, I encountered this assert:

http://hg.openjdk.java.net/jdk/jdk/file/ca1687338afe/src/hotspot/share/gc/g1/g1HeapVerifier.cpp#l337

assert(!cl.has_unexpected_holes(), "all holes should have been caused by humongous regions");

During -Xshare:dump, we would force a GC, 

http://hg.openjdk.java.net/jdk/jdk/file/ca1687338afe/src/hotspot/share/memory/metaspaceShared.cpp#l1870

Usually this will clear the EDEN region, leaving the top of the heap unused. Here's the log from java -Xshare:dump -Xlog:gc*=info,gc+region=trace,gc+alloc+region=debug

(see attached good.txt)
[4.742s][info ][cds            ] Dumping symbol table ...
[4.812s][info ][gc,region,cds  ] HeapRegion 0x00000003d2000000 OLD
[4.812s][info ][gc,region,cds  ] HeapRegion 0x00000003d2800000 FREE
[4.812s][info ][gc,region,cds  ] HeapRegion 0x00000003d3000000 FREE
[4.812s][info ][gc,region,cds  ] HeapRegion 0x00000003d3800000 FREE
[4.812s][info ][cds            ] Dumping objects to closed archive heap region ...


However, when the bug happens, we see an EDEN region at the top of the heap, which CDS doesn't want to see:

(see attached bad.txt)
[1.370s][info ][cds            ] Dumping symbol table ...
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080000000 OLD
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080100000 OLD
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080200000 FREE
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080300000 FREE
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080400000 FREE
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080500000 FREE
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080600000 FREE
[1.387s][info ][gc,region,cds  ] HeapRegion 0x0000000080700000 EDEN hole **** unexpected ****
[1.387s][warning][gc,verify      ] All free regions should be at the top end of the heap, but we found holes. This is probably caused by (unmovable) humongous allocations, and may lead to fragmentation while writing archive heap memory regions.
[1.388s][info   ][cds            ] Dumping objects to closed archive heap region ...
Comments
Changeset: c82c50b2 Author: Ioi Lam <iklam@openjdk.org> Date: 2020-06-14 01:19:48 +0000 URL: https://git.openjdk.java.net/lanai/commit/c82c50b2
02-07-2020

Changeset: c82c50b2 Author: Ioi Lam <iklam@openjdk.org> Date: 2020-06-14 01:19:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c82c50b2
02-07-2020

Changeset: c82c50b2 Author: Ioi Lam <iklam@openjdk.org> Date: 2020-06-14 01:19:48 +0000 URL: https://git.openjdk.java.net/amber/commit/c82c50b2
02-07-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/06bc0ab0a060 User: iklam Date: 2020-06-14 08:20:57 +0000
14-06-2020

ILW = HLL = P4
02-06-2020

I forced a crash when the EDEN region is allocated after CDS has executed the GC. See attachment hs_err.txt. The allocation happens here: j java.util.zip.Inflater.end(J)V+0 java.base@15-internal j java.util.zip.Inflater$InflaterZStreamRef.run()V+17 java.base@15-internal j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base@15-internal j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base@15-internal j java.util.zip.Inflater$InflaterZStreamRef.clean()V+4 java.base@15-internal j java.util.zip.Inflater.end()V+11 java.base@15-internal j java.util.zip.ZipFile$CleanableResource.run()V+32 java.base@15-internal j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base@15-internal j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base@15-internal j jdk.internal.ref.CleanerImpl.run()V+77 java.base@15-internal j java.lang.Thread.run()V+11 java.base@15-internal j jdk.internal.misc.InnocuousThread.run()V+20 java.base@15-internal This happens after the GC, but before VM_PopulateDumpSharedSpace::doit() is executed.
27-05-2020