RFR: 8204686: Dynamic parallel reference processing support for Parallel GC

[Thomas Schatzl]

On Fri, 28 May 2021 15:26:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The first part:
> 1) sets `ParallelRefProcEnabled` to true if we have multiple threads (in Parallel)
> 2) removes the field `_adjust_no_of_processing_threads` so that Parallel and G1 handles dynamic resizing the same
> 3) removes an early return --- `ergo_proc_thread_count()` already adjusts for `ReferencesPerThread == 0`
> 
> The second part tries something else. It makes `ParallelRefProcEnabled` default to true for all GCs and does not take into consideration the amount of gc threads. I have talked to Thomas Schatzl  before posting this and we will probably *not* use part two. Reasons include that we can then no longer read the flag ParallelRefProcEnabled to see if we are going to do parallel ref processing as it will be true even if we only have one thread (or are running Serial GC). I still want to show the possibility.
> 
> Part three shows the impact on test cases when part two is applied. I will need to adjust part three if we remove Part 2.
> 
> Please take an extra look at the removal of the early return, it looks valid to me and `hotspot_gc` passes.
> 
> I will try to get this into 17, but if review and CSR takes time I will postpone it to 18. I suggest dropping part 2 and will do so if no one objects.

I think part 2 should be dropped: it is always a help for debugging performance issues to see what `ParallelRefProcEnabled` is (with `-XX:+PrintFlagsFinal`) if it can be determined at startup whether parallel reference processing is (not) active.

I.e. whether there is absolutely no chance that the VM will use parallel gc threads for reference processing is already useful information. Particularly for serial gc it might mislead people if `ParallelRefProcEnabled` were `true` for it. Not sure if changing the description of the flag is necessary, but I see that there might be some ambiguity.

This is not a hard no for keeping part2, but unless there are good reasons to keep it I would suggest dropping this change.

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

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