RFR: 8350285: Regression caused by ShenandoahLock under extreme contention

[Xiaolong Peng]

On Wed, 19 Feb 2025 18:05:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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()`.

It is like more than 2x worse, but still much better(10x) than tip and revert of JDK-8331411, here are the top 10 at-safepoint time for comparison:
10 us:

7982953
5043319
5008139
4597156
4580556
4429245
4403175
4047891
3677389
3582308


100 us:

4553716
1703093
1046248
1038148
780447
778786
778436
778276
728716
721856


I can change it to same seep time for all platforms, but Windows doesn't really support nanosecond resolution sleep, JVM use combination of yield and spin pause to approximate nanosecond resolution sleep for Windows, it should be still fine since it won't be worse then only `yield` as before. In short, I am not expecting any improvement for Windows.

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

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