RFR: 8317371: GenShen: Needs improved support for humongous allocation [v3]

[Kelvin Nilsen]

On Thu, 12 Oct 2023 18:07:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cosmetic improvements
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 570:
> 
>> 568:     case ShenandoahAllocRequest::_alloc_shared: {
>> 569:       // Try to allocate in the mutator view
>> 570:       // Allocate within mutator free from high memory to low so as to preserve low memory for humongous allocations
> 
>> a. Allocating regular objects from top end of memory while allocating humongous from bottom end of memory
> 
> Don't we usually take the collector reserve from the top end of the heap? Would it make sense to assume humongous objects tend to be long lived and allocate them from the back of the heap?

You are correct that the top of heap has Old Collector Reserve, then Collector reserve.  So there is an established practice of putting longer-lived objects at the top of the heap.  In the existing implementation, we start the search for a humongous heap region at the bottom of the heap.

I think it will not matter much whether we allocate humongous from top or bottom of heap.  The important thing is that we do not allocate long-lived object in the "middle" of the heap, as this hinders allocation of humongous objects.  It feels a little bit simpler to me to keep the humongous objects in a different memory than the rest of the old collector reserve (and retired old-gen regions).  The top of memory experiences churn as the result of mixed evacuations to "compact" old-gen memory, whereas the bottom of memory should be largely empty most of the time.

The problem occurs when the mutator has to allocate all the way to the bottom of the heap before GC finishes and replenishes the mutator free set.  If some of the bottom-of-memory mutator allocations are subsequently promoted in place (and this has been observed in practice), we end up with fragmentation of the low-memory address range that we want to reserve for humongous allocations.  This is when we trigger old_is_fragmented(), so these bottom-of-memory promoted-in-place regions can be evacuated into top-of-memory regions, and humongous allocation space can be restored.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/336#discussion_r1357311562