On Thu, 11 Jul 2024 18:09:24 GMT, Albert Mingkun Yang <ay...@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
