On Mon, 7 Jul 2025 00:39:59 GMT, Zhengyu Gu <z...@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
