RFR: 8301116: Parallelize TLAB resizing in G1 [v2]

[Thomas Schatzl]

On Fri, 3 Feb 2023 11:25:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>>> Using `Threads::possibly_parallel_oops_do`, thread iteration/claiming seems to be the bottleneck, i.e. claiming the token.
>>> 
>>> One issue is that all threads need to traverse the array from the beginning to get to the current claim position - so the minimum processing time for a single thread is iterating the complete thread array and checking all tokens for it. That does not matter so much if the work per thread is big (like when walking the stacks for oops - but even then I think it would be noticable, need to check).
>>> 
>>> The other is that with little work per thread threads like in this situation they seem to be contending heavily on the JavaThread claim tokens, so this "parallelization" is quite a pessimization - I've measured ~4x slower with 18 threads than using the single-threaded version (on ~21k JavaThreads)
>> 
>> Looking at `Threads::possibly_parallel_threads_do`, I'm thinking it could use a redesign to use the technique
>> being used in `G1JavaThreadsListClaimer`.  The existing design and implementation dates from when the
>> threads-list was an actual linked list, rather than the newer ThreadsList.  But maybe that's future work.
>
>> > Using `Threads::possibly_parallel_oops_do`, thread iteration/claiming seems to be the bottleneck, i.e. claiming the token.
>> > One issue is that all threads need to traverse the array from the beginning to get to the current claim position [...]
>> > The other is that with little work per thread threads like in this situation they seem to be contending heavily on the JavaThread claim tokens [...]
>> 
>> Looking at `Threads::possibly_parallel_threads_do`, I'm thinking it could use a redesign to use the technique being used in `G1JavaThreadsListClaimer`. The existing design and implementation dates from when the threads-list was an actual linked list, rather than the newer ThreadsList. But maybe that's future work.
> 
> I considered that, but the non-java threads still use the linked list design, so I moved that to future work :) I can investigate that a bit more though, but would like to keep it as is for this change.

> I think a better solution might be to declare the `Thread::_tlab` member `mutable` and `Thread::tlab() const`.

The code works as is without the removed `const` after all, so I'm not sure I should do this suggested change.

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

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