RFR(S) 8245925 G1 allocates EDEN region after CDS has executed GC

[Yumin Qi]

HI, Ioi

   If the allocation of EDEN happens between GC and dump, should we put 
the GC action in VM_PopulateDumpSharedSpace? This way, at safepoint 
there should no allocation happens. The stack trace showed it happened 
with a Java Thread, which should be blocked at safepoint.

Thanks
Yumin

On 5/29/20 7:29 PM, Ioi Lam wrote:
> https://bugs.openjdk.java.net/browse/JDK-8245925
> http://cr.openjdk.java.net/~iklam/jdk15/8245925-g1-eden-after-cds-gc.v01/
>
>
> Summary:
>
> CDS supports archived heap objects only for G1. During -Xshare:dump,
> CDS executes a full GC so that G1 will compact the heap regions, leaving
> maximum contiguous free space at the top of the heap. Then, the archived
> heap regions are allocated from the top of the heap.
>
> Under some circumstances, java.lang.ref.Cleaners will execute
> after the GC has completed. The cleaners may allocate or synchronized, 
> which
> will cause G1 to allocate an EDEN region at the top of the heap.
>
> The fix is simple -- after CDS has entered a safepoint, if EDEN 
> regions exist,
> exit the safepoint, run GC, and try again. Eventually all the cleaners 
> will
> be executed and no more allocation can happen.
>
> For safety, I limit the retry count to 30 (or about total 9 seconds).
>
> Thanks
> - Ioi
>
>
> <https://bugs.openjdk.java.net/browse/JDK-8245925>