RFR: 8265842: G1: Introduce API to run multiple separate tasks in a single gangtask

[Thomas Schatzl]

On Tue, 27 Apr 2021 09:24:08 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> [...]
> I'm not sure I exactly understand how `setup()` would be used, but a `run_batched_task(...)` might help some of the duplication:
> [...]

Exactly that has been introduced in the follow-up change.

>[...]
> 
> Basically the only other question/concern I have after looking at the patch is if we can some how get rid or change `num_busy_workers()`. I guess we might need some way to estimate the needed number of workers but does it have to return a `double`. To me it is strange that something can require a fraction of a worker. I understand that certain task are very small and for those we could consider returning 0. Or would that cause other problems?

Generally there are two interesting cases when running a gang task: using one (or maybe two) threads, and using all of them as indicated by `WorkGang::active_workers()`. Particularly with more sub tasks in a batch the latter will probably more common than now, so the "in-between" ones will be exceedingly rare.

The case where we use just one worker is particularly interesting though: we could avoid spinning up a worker thread in this case completely, using the VM thread to execute the batch (all gang tasks at least in G1 support that at this time, we just do not do it). With an integer `num_busy_workers()` value it is very hard to achieve that (i.e. `sum(num_busy_workers()) <= 1.0` given such a batch task always contains at least few serial tasks. And if everyone returns 1 at minimum, there is no way this will work reasonably.

Note that currently (and in that follow-up CR) particularly for these serial tasks the `num_busy_workers()` return value isn't particularly well set (and I just recently "fixed" one for a parallel task...) so that there is a good chance it will not work out of the box, but we haven't enabled using the VM thread anyway yet.
And there is the question whether we can somehow either completely drop or move to concurrent some of that work; however in many cases pre/post evacuation work is very small compared to actual evacuation. Work for another day...

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

PR: https://git.openjdk.java.net/jdk/pull/3653