RFR: 8331609: GenShen: Refactor generational mode allocations [v4]

[William Kemper]

On Tue, 7 May 2024 21:36:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 243:
>> 
>>> 241:   }
>>> 242: 
>>> 243:   // This is a shared allocation promotion request. However, we do not have room for any
>> 
>> How do we know this is NOT a shared allocation evacuation request?  Is there a precondition on the method call?
>> 
>> Implementation below looks we're not sure this is a promotion.  We still need to check.
>> 
>> I think what we're saying here is:
>>   if req.is_promotion();   return false because we already checked above, and found that can_promote(requested_bytes) to be false.
>>   
>>   So what if req is not promotion?  wouldn't we want to confirm that get_evacuation_reserve() > requested_bytes?
>
>> How do we know this is NOT a shared allocation evacuation request?
> 
> We check if the request type is  `ShenandoahAllocRequest::_alloc_plab` on line 239.
> 
>> So what if req is not promotion? wouldn't we want to confirm that get_evacuation_reserve() > requested_bytes?
> 
> [The previous version of this code](https://github.com/openjdk/shenandoah/pull/427/files#diff-5ca0a05384b7b2604dd3c9b55d91a7010a42cd0ba246600c844e19821bd6b60bL1178) had a comment for this case (i.e., shared evacuation) that read:
> 
> // This is a shared allocation for evacuation. Memory has already been reserved for this purpose.
> 
> https://github.com/openjdk/shenandoah/pull/427/files#diff-5ca0a05384b7b2604dd3c9b55d91a7010a42cd0ba246600c844e19821bd6b60bL1178
> 
> I believe this change preserves the original behavior, but it makes sense to me to also enforce evacuation reserve constraints for `shared` evacuations.

I've fixed these comments.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/427#discussion_r1594808624