RFR: 8341379: Shenandoah: Improve lock contention during cleanup

Kelvin Nilsen kdnilsen at openjdk.org
Wed Oct 2 23:09:36 UTC 2024


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'll modify the code to adjust for current localized behavior of the host computer.  (e.g. not hard-code assumptions about task durations.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2389933286


More information about the hotspot-gc-dev mailing list