RFR: Shrink tlab to capacity [v2]

[Kelvin Nilsen]

On Mon, 12 Dec 2022 21:31:22 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify recursive implementation of allocate_memory_under_lock
>>   
>>   (with a comment)
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1368:
> 
>> 1366:   // satisfy the allocation request.  The reality is the actual TLAB size is likely to be even smaller, because it will
>> 1367:   // depend on how much memory is available within mutator regions that are not yet fully used.
>> 1368:   HeapWord* result = allocate_memory_under_lock(smaller_req, in_new_region, is_promotion);
> 
> Can you help me understand the structure here.
> 
> Would it not have been simpler to keep sufficient state at the point where the attempt to allocate the larger size failed, and we decided we would shrink the size of the request, to just make the smaller allocation request which would be guaranteed to succeed because we held the heap lock at that point already? Is there a reason to give up and reattempt the smaller allocation request afresh?
> 
> I realize you explicitly added a scope to make this re-attempt outside the scope of the locker and make the recursive call, but am trying to understand the rationale for doing so. Perhaps it's because I am missing the big picture of the work being done here from various callers to this method, but may be you can help clarify that a bit.

Thanks for your review.  I'm adding a comment to clarify the recursive algorithm and use of secondary ShenandoahAllocationRequest argument.

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

PR: https://git.openjdk.org/shenandoah/pull/180