RFR: 8350285: Regression caused by ShenandoahLock under extreme contention

[Aleksey Shipilev]

On Wed, 19 Feb 2025 17:27:15 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahLock.hpp line 61:
>> 
>>> 59: #else
>>> 60:     os::naked_short_nanosleep(100000);
>>> 61: #endif
>> 
>> Any context where this is coming from? This looks like from `SpinYield`? If so, should we target `SpinYield::default_sleep_ns=1000`?
>
> It is just a magic number we tested, not from `SpinYield`. I chose 100us because Shenandoah GC pause is usually less then 1ms, I also tested 10us but 100us was better in the test.

I looked around HS sources, and I think the closest primitive we have is `HandshakeSpinYield`, which does 10us sleeps. How much worse is 10us in comparison to 100us in your tests? I would prefer to do 10us for all platforms, if performance tests allow us. This would also allow you to inline `short_sleep()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23701#discussion_r1962150403