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