RFR: 8341379: Shenandoah: Improve lock contention during cleanup

[Paul Hohensee]

On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort.  The affected code runs at the end of FinalMark to reclaim immediate garbage.  It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
> 
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
> 
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
> 
> Without this change, latency for 4 un-named business services is represented by the following chart:
> ![image](https://github.com/user-attachments/assets/0e36025b-7b76-4e7a-ab07-303ea49479c3)
> 
> With this change, latency for the same services is much better:
> ![image](https://github.com/user-attachments/assets/aceaf185-6944-4c91-b98e-06ccd1bc2d64)
> 
> A comparison of the two is provided by the following:
> ![image](https://github.com/user-attachments/assets/7145f7b5-2a65-44b0-a94a-ddbc871f236b)

I worry that we're hard-coding assumed task durations. I'm ok with this PR as it is, but I suggest we add a facility to GC initialization that does dummy tasks such as this in order to get somewhat-realistic times for use in this kind of situation.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21211#pullrequestreview-2344117544