RFR: 8350285: Regression caused by ShenandoahLock under extreme contention

[Xiaolong Peng]

On Wed, 19 Feb 2025 21:28:40 GMT, Xiaolong Peng <xpeng 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.

I have tested 3/5/7, safepoint time is very close in the tests with 3 or 5 yields(3 is slightly better), but it is worse with 7, I can change it to 3.

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

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