RFR: 8302122: Parallelize TLAB retirement in prologue in G1
Thomas Schatzl
tschatzl at openjdk.org
Mon Feb 13 09:41:27 UTC 2023
On Sun, 12 Feb 2023 02:57:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>> Hi all,
>>
>> can I have reviews for this change that parallelizes TLAB retirement and log buffer flushing (which [JDK-8297611](https://bugs.openjdk.org/browse/JDK-8297611) suggests?
>>
>> * the parallelization has been split into java and non-java threads: parallelization of the latter does not make sense given how they are organized in a linked list. However non-java threads are typically very few anyway, and parallelization only starts making sense with low hundreds of threads anyway.
>> * `G1BarrierSet::write_region` added a new parameter that describes the JavaThread the write_region/invalidation (not sure why `write_region` isn't just an overload of `invalidate`) is made for. The reason is previously when `BarrierSet::make_parsable()` (not sure why this is called this way either) is called to flush out deferred card marks, the card marks generated by that were added to the *calling thread's* refinement queue. This worked because the calling thread (the worker thread/vm thread) has always been processed after all java threads (which are the only ones that can have deferred card marks). So these deferred card marks' refinement entries were put into the worker thread's refinement queue. After parallelization this is not possible any more unless we deferred non java thread log flushing until after all java threads - I did not want to do that, so the change passes that explicit java thread through to `G1BarrierSet::write_region`. I think this is clearer anyway, and
corresponds to how `G1DirtyCardQueueSet::concatenate_log_and_stats` works.
>>
>> Testing: tier1-5
>>
>> Thanks,
>> Thomas
>
> src/hotspot/share/gc/g1/g1YoungGCPreEvacuateTasks.cpp line 185:
>
>> 183: total_refinement_stats += _non_java_stats->refinement_stats();
>> 184: qset.update_refinement_stats(total_refinement_stats);
>> 185:
>
> Shouldn't there be something here to delete `_java_stats` and `_non_java_stats`?
Both are actually the tasks that after adding them to the batchtask are owned and deleted by it. I'll rename the variables because otherwise it is confusing (I went back and forth with the names of these multiple times and apparently chose the more confusing option).
-------------
PR: https://git.openjdk.org/jdk/pull/12497
More information about the hotspot-gc-dev
mailing list