RFR: 8227060: Optimize safepoint cleanup subtask order [v2]

[Coleen Phillimore]

On Sat, 16 Jul 2022 00:50:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Kim's improvement ideas.
>
> A bit of history here. It seems that some of the point of the original CR has
> disappeared. There used to be a use of parallel_java_threads_do at the start
> (from JDK-8180932), with the CR suggesting moving that to the end. That
> disappeared with JDK-8246476. So some of the point of the CR has gone away.
> But ordering the remaining tasks from expensive to cheap is still sensible,
> and the new order mostly [*] looks plausible.
> 
> A different (pre-existing) problem is that the use of the workers isn't great.
> The amount of parallelism is just the workgang's current `active_workers()`,
> with no regard to how much parallelism we have. Presently the maximum useful
> amount of parallelism is the number of subtasks, so 6 (which might easily and
> likely be reduced with some pre-checks). So we're going to apply
> `active_workers` threads (whatever that happens to be at the moment) to a task
> which can use only a relatively small and fixed [*] number of threads.
> Improving the use of the workgang should be a separate RFE.
> 
> [*] JDK-8253180 later (after JDK-8246476) introduced the serial threads_do to
> set GC watermarks. Digging into it a bit, that doesn't look obviously
> lightweight; I wonder if it should be (should have been) parallelized (and
> placed at the end of the work). But that's a separate RFE.

@kimbarrett I made your suggested improvements, even though a class in the middle of function looks odd to me.   Maybe someday it can be replaced with a lambda.  Reran tier1 tests locally.  I agree that the problem that this was supposed to solve may be gone now, but if we do resizing and rehashing, it would be good to have that in parallel with the other tasks.  The threads are already created, otherwise the cost of creating them would not be worth making this parallel.  I can't comment on how much work the lazy stack watermark processing is.

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

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