RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v2]
Joel Sikström
jsikstro at openjdk.org
Thu Jun 12 12:40:27 UTC 2025
On Thu, 12 Jun 2025 09:23:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> Joel Sikström has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - -Wconversion fixes
>> - Intermediate alloc_object in ZHeap
>
> The change looks good. But I have a few thoughts if we want to take this a step further.
>
> This change starts adding a static interface on `ZObjectAllocator` which is used for `retire_pages`. I wonder if we can take this all the way and make `ZObjectAllocator` a static only interface. And keep the Allocator implementation opaque / private.
>
> So instead of first pulling out the allocator and calling the corresponding function, we go through the static interface. So we get something like
> ```c++
> static void initialize();
> static void retire_pages(ZPageAgeRange range);
> static zaddress alloc_object(size_t size, ZPageAge age);
> static void undo_alloc_object(zaddress addr, size_t size, ZPageAge age);
> static size_t remaining_in_eden();
Thank you for the feedback @xmas92!
I addressed your comments in a new commit. Do you think we should now rename the zObjectAllocator{.hpp, .inline.hpp, cpp} to zObjectAllocators instead, now that the static interface is the new "accessor"?
If you have any thoughts on my comment about making the ZObjectAllocator constuctor private I'm open to suggestions.
> src/hotspot/share/gc/z/zObjectAllocator.hpp line 44:
>
>> 42: static constexpr uint NumRelocationAllocators = NumAllocators - 1;
>> 43:
>> 44: typedef Deferred<ValueObjArray<ZObjectAllocator, NumAllocators>> Allocators;
>
> Nit, I prefer `using` over `typedef`.
> Suggestion:
>
> using Allocators = Deferred<ValueObjArray<ZObjectAllocator, NumAllocators>>;
Sure!
> src/hotspot/share/gc/z/zObjectAllocator.hpp line 85:
>
>> 83: static ZObjectAllocator* eden();
>> 84:
>> 85: static void retire_pages(ZPageAgeRange range);
>
> We tend to avoid mixing static and non static interfaces.
>
> Maybe adding a `ZObjectAllocators` to wrap the static interface is preferable.
I added an AllStatic ZObjectAllocators. I think this looks good. I couldn't get around not having the ZObjectAllocator constructor being public so that ValueObjArray can access it. Adding ValueObjArray as a friend did not work either, maybe there's a better way to do this but I'm not sure.
> src/hotspot/share/gc/z/zObjectAllocator.inline.hpp line 43:
>
>> 41: guarantee(size <= ZHeap::heap()->max_tlab_size(), "TLAB too large");
>> 42: return alloc_object(size);
>> 43: }
>
> This could probably be on `ZHeap` instead and only have `alloc_object` on `ZObjectAllocator`
I agree, we don't have to include ZObjectAllocator in zCollectedHeap.cpp any more as well, and the guarantee check fits better in ZHeap instead of here.
> src/hotspot/share/gc/z/zObjectAllocator.inline.hpp line 47:
>
>> 45: inline void ZObjectAllocator::retire_pages(ZPageAgeRange range) {
>> 46: for (ZPageAge age : range) {
>> 47: _allocators->at((int)untype(age))->retire_pages();
>
> Suggestion:
>
> allocator(age)->retire_pages();
👍
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25693#issuecomment-2966542623
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142626884
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142625860
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142621460
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142626528
More information about the hotspot-gc-dev
mailing list