RFR: 8301116: Parallelize TLAB resizing in G1
Thomas Schatzl
tschatzl at openjdk.org
Thu Feb 2 09:23:29 UTC 2023
On Thu, 2 Feb 2023 05:24:53 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Hi all,
>>
>> can I get reviews for this change that moves TLAB resizing into the second parallel post evacuation phase?
>>
>> The change is fairly straightforward except maybe for the following:
>> * there is a new claimer for `JavaThreads` because the `Threads::possibly_parallel_threads_do` method to parallelize does not work well with very little per-thread work. Actually with a moderate amount of threads (~20) performance would already be many times slower than doing things serially.
>> * moving the TLAB resizing out of `G1CollectedHeap::prepare_tlabs_for_mutator` made that method and the enclosing timing a bit obsolete, so I repurposed it as a "do preparatory work for the mutator during young gc" phase. That resulted in minor cleanup and regularization of what is done during that phase (wrt to what the corresponding method for full gc does).
>>
>> Testing: gha, local perf testing, tier1
>>
>> Thanks,
>> Thomas
>
> src/hotspot/share/runtime/threadSMR.hpp line 204:
>
>> 202: JavaThread *const thread_at(uint i) const { return _threads[i]; }
>> 203:
>> 204: JavaThread *const *threads() const { return _threads; }
>
> Seems an unrelated change. ??
No, the operations on the `JavaThread` during these phases change the `JavaThread` state (actually, the referenced TLAB state).
E.g. `g1YoungGCPostEvacuateTasks.cpp:720`:
void do_work(uint worker_id) override {
JavaThread* const* list;
uint count;
while ((list = _claimer.claim(count)) != nullptr) {
for (uint i = 0; i < count; i++) {
list[i]->tlab().resize(); <--- here, the tlab needs to be modified (but not the JavaThread)
}
}
}
I could `const_cast` that one away, but that seemed really ugly to me.
In a follow-up change there is a similar access to the threads' TLAB. Maybe there is a better way to do that (apart from `const_cast`ing).
-------------
PR: https://git.openjdk.org/jdk/pull/12360
More information about the hotspot-gc-dev
mailing list