RFR: 8350285: Regression caused by ShenandoahLock under extreme contention

[Xiaolong Peng]

On Wed, 19 Feb 2025 21:21:42 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Yielding 5x for every 1 nanosleep seems a bit "arbitrary". I assume you found that the number 5 delivered the "best performance" compared to other numbers you might have chosen. I wonder if different architectures with different numbers of cores, different operating systems, and/or different test applications that have different numbers of runnable threads would also perform best with this same magic number 5.
> 
> Could we at least add a comment explaining how/why we chose 5 here?

5 is from the old implementation, the old implementation was copied from https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/thread.cpp#L577

I can do a bit more test on this, and add some comments to explain why we choose the magic number 5.

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

PR Comment: https://git.openjdk.org/jdk/pull/23701#issuecomment-2669800369