RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3]

[Kim Barrett]

On Tue, 27 Sep 2022 12:44:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - wanted vs needed nomenclature
>>  - remove several spurious "scan"
>>  - delay => wait_time_ms
>
> Some typos. Going to do some testing.

@tschatzl did some additional performance testing and found a regression. The
periodic remset sampling with associated young gen target length adjustment
can interact poorly with this change. This change tries to be lazy about
performing the concurrent refinement, delaying to late in the mutator phase.
Because the target length adjustment happens relatively infrequently (300ms
period by default), it may make a large change. But if the length is reduced
by enough to make a GC needed soon, it may be too late to do much of the
needed refinement. This can lead to significantly increased pause time. The
solution is to move the target length adjustment into the primary refinement
thread.  Currently doing more perf testing.

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

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