RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]

[Albert Mingkun Yang]

On Mon, 7 Jul 2025 00:39:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> I don't see how I changed the semantics.
>> 
>> On baseline, from `mem_allocate_work`:
>> 
>> 
>> if (result != nullptr) {
>>   return result;
>> }
>> 
>> // If certain conditions hold, try allocating from the old gen.
>> if (!is_tlab) {
>>   result = mem_allocate_old_gen(size);
>>   if (result != nullptr) {
>>     return result;
>>   }
>> }
>> 
>> 
>> and
>> 
>> 
>> HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
>>   if (!should_alloc_in_eden(size)) {
>>     // Size is too big for eden.
>>     return allocate_old_gen_and_record(size);
>>   }
>> 
>>   return nullptr;
>> }
>> 
>> 
>> The original logic is essentially:
>> 
>> 
>> if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
>>   // allocate in old-gen
>> }
>> 
>> which is the same as I put here.
>
> Ah, okay.

I took another look at this and realized that there are to paths to do retry-allocation-in-old-gen-after-young-gen-failure.

1. In `mem_allocate_work`.


      HeapWord* result = young_gen()->allocate(size);
      if (result != nullptr) {
        return result;
      }

      // If certain conditions hold, try allocating from the old gen.
      if (!is_tlab && !should_alloc_in_eden(size)) {
        result = old_gen()->cas_allocate_noexpand(size);


This retry-allocation-in-old-gen is *pre-gc* -- the `should_alloc_in_eden` filter is there to ensure that a (young) gc should kick-in, instead of populating old-gen with many small objs.

2. In `satisfy_failed_allocation` -> `expand_heap_and_allocate`.


  HeapWord* result = young_gen()->expand_and_allocate(size);

  if (result == nullptr && !is_tlab) {
    result = old_gen()->expand_and_allocate(size);
  }


This retry-allocation-in-old-gen is *post-gc* -- we should not artificially introduce old-gen-allocation-failure, because that would mean the previous (young/full) gc was useless to this allocation-request.

Therefore, I believe the logic on master is more reasonable. Also, for back compatibility reasons, I have reverted this part and added a comment there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2194344731