RFR: 8332455: Improve G1/ParallelGC tasks to not override array lengths

[Kim Barrett]

On Fri, 5 Jul 2024 15:04:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > I have a couple of ideas for alternative mechanisms that I might explore.
> 
> Would you mind sharing the ideas?

I'll respond to other points separately.

Here's a (very drafty) suggestion.
https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:array-splitting?expand=1

(There are lots of specific details about these changes that I don't like, and
would want to do a bit differently in a real PR, but it demonstrates the
approach, and has passed basic testing. Note that it requires disabling
ParallelGC for now to build, e.g. --disable-jvm-feature-parallelgc. There are
lots of comments that haven't been updated to reflect associated code
changes.)

The idea is to define a C++ object that represents the state of the iteration
over an array. So at a minimum the new array and the next array index to start
processing from. (We might have other members for convenience, or for use by
other variants than the current usage by G1.) The associated ScannerTask
entries in the taskqueue contain a pointer to the state object associated with
an array. We allocate the state object when we decide to parallelize the
scanning of the array.

Use arena allocation for the state objects, so we don't have to search the
taskqueues to reclaim them if we need to discard the contents of the queues
(such as when we sometimes abort G1 concurrent marking).

Put a free-list allocator in front of the arena allocator, so the high water
mark for allocation is based on the number of in-progress arrays rather than
the total number that exist.

The states are reference counted, so we know when to return them to the
free-list. Each referring ScannerTask we insert in a taskqueue increases the
count. When we take one out and have finished processing it then decrement the
count. Release the state when its count reaches zero. Manipulation of tasks
inside a task queue doesn't need to manipulate the count. While a ScannerTask
might get copied around in the queues, that mechanism ensures the number of
copies ultimately doesn't change over what's inserted and later taken out for
processing.

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

PR Comment: https://git.openjdk.org/jdk/pull/19282#issuecomment-2217172431