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

[Ioi Lam]

On 5/29/20 9:40 PM, Yumin Qi wrote:
> 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.
>

Hi Yumin,

I think GCs cannot be executed inside a safepoint, because some parts of 
GC need to execute in a safepoint, so they will be blocked until 
VM_PopulateDumpSharedSpace::doit has returned.

Anyway, as I mentioned in my reply to Jiangli, there's a better way to 
fix this, so I will withdraw the current patch.

Thanks
- Ioi

> 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>
>