RFR: 8344665: Refactor PartialArrayState allocation for reuse [v2]

Ivan Walulya iwalulya at openjdk.org
Thu Nov 28 10:57:39 UTC 2024


On Fri, 22 Nov 2024 11:00:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change splits the existing PartialArrayStateAllocator class into an
>> allocator class and a manager class.  The allocator class is per worker
>> thread.  The manager class provides the memory management context for a
>> group of allocators.
>> 
>> This change is in preparation for some other refactorings around partial array
>> state handling.  That work is intended to make it easier for various
>> collections to adopt the use of that mechanism for chunking the processing of
>> large objArrays.
>> 
>> The new implementation for the memory management context is based on the
>> existing one, with an Arena per worker, now controlled by the manager object.
>> Potential improvements to that can be explored in the future.  Some ideas
>> include improvements to the Arena API or a single thread-safe Arena variant
>> (trading slower arena allocation (which is the slow path) for less memory
>> usage).
>> 
>> G1 has a single manager, reused by each young/mixed GC. Associated state
>> allocators are nested in the per-worker structures, so deleted at the end of
>> the collection. The manager is reset at the end of the collection to allow the
>> memory to be recycled. It is planned that the STW full collector will also use
>> this manager when converted to use PartialArrayState. So it will be reused by
>> all STW collections.
>> 
>> ParallelGC has a single manager, reused by each young collection. Because the
>> per-worker promotion managers are never destroyed, their nested state
>> allocators are never destroyed. So the manager is not reset, instead leaving
>> previously allocated states in the allocator free lists for use by the next
>> collection. This means the full collector won't be able to use the same
>> manager object as the young collectors.
>> 
>> Testing: mach5 tier1-5
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify pas allocator destruction and manager phase tracking

src/hotspot/share/gc/shared/partialArrayState.hpp line 176:

> 174: 
> 175:   // Limit on the number of allocators this manager supports.
> 176:   uint _num_allocators;

_max_num_allocators; the comment helps, but we can add max to the name.

src/hotspot/share/gc/shared/partialArrayState.hpp line 185:

> 183:   // - low half: allocators constructed
> 184:   // - high half: allocators destructed (debug only)
> 185:   volatile CounterState _counters;

Seems like a lot of code overhead to accomodate debugging! However, if there is no easier approach, then not a blocker for me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22287#discussion_r1861960042
PR Review Comment: https://git.openjdk.org/jdk/pull/22287#discussion_r1861963894


More information about the hotspot-gc-dev mailing list