RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3]

[Guoxiong Li]

On Thu, 11 Jul 2024 18:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 478:
>> 
>>> 476: 
>>> 477:     const bool clear_all_soft_refs = true;
>>> 478:     do_full_collection_no_gc_locker(clear_all_soft_refs);
>> 
>> If the young collection succeeded in method `collect_at_safepoint`. The normal full collection won't run in `collect_at_safepoint`. If the successful young collection didn't release any memory (or only released little memory but not enough for allocation), the allocation in line 462 will fail too. Then a full collection with maximum compaction will be run. It is strange. In my opinion, I think the steps look like below:
>> 
>> 1. allocation
>> 2. young collection
>> 3. allocation
>> 4. normal full collection
>> 5. allocation
>> 6. maximum full collection
>> 7. allocation
>> 8. OOM
>> 
>> But in current patch, the step 4-5 may be skipped.
>
>> If the successful young collection didn't release any memory (or only released little memory but not enough for allocation),
> 
> A successful young-gc often leave young-gen completely empty. Otherwise, max-compaction full-gc should be run -- there is little benefit of running non-max-compaction full-gc if old-gen is too packed to hold all young-gen objs.

Thanks for your explanation. I am OK with the current solution now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674923459