On Fri, 12 Jul 2024 01:22:28 GMT, Guoxiong Li wrote:
>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 446:
>>
>>> 444: }
>>> 445: return result; // Could be null if we are out of space.
>>> 446: }
>>
>> I notice the method `PSOldGen::allocate` can expand the size of the old
On Thu, 11 Jul 2024 15:40:01 GMT, Guoxiong Li wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains three
>> additional
On Thu, 11 Jul 2024 18:09:24 GMT, Albert Mingkun Yang 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 succ
On Thu, 11 Jul 2024 17:10:58 GMT, Guoxiong Li wrote:
> 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 --
On Thu, 11 Jul 2024 14:39:47 GMT, Guoxiong Li wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains three
>> additional
On Wed, 10 Jul 2024 20:29:37 GMT, Albert Mingkun Yang wrote:
>> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in
>> Parallel. As a result, the corresponding code in `SerialHeap` and
>> `ParallelScavengeHeap` share much similarity.
>>
>> The easiest way to review is to start
> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel.
> As a result, the corresponding code in `SerialHeap` and
> `ParallelScavengeHeap` share much similarity.
>
> The easiest way to review is to start from these two VM operations,
> `VM_ParallelCollectForAllocation` a