RFR: 8302122: Parallelize TLAB retirement in prologue in G1 [v3]

[Albert Mingkun Yang]

On Wed, 15 Feb 2023 12:00:28 GMT, Thomas Schatzl <tschatzl 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
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Minor subjective suggestion.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 476:

> 474:     G1PreEvacuateCollectionSetBatchTask cl;
> 475:     G1CollectedHeap::heap()->run_batch_task(&cl);
> 476:     phase_times()->record_pre_evacuate_prepare_time_ms((Ticks::now() - start).seconds() * 1000.0);

"PreEvacuate" and "pre_evacuate_prepare" seems too abstract/generic. Maybe sth more concrete to reflect what it is, not how it is connected/compared to its context.

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

Marked as reviewed by ayang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12497