RFR: 8331411: Shenandoah: Reconsider spinning duration in ShenandoahLock [v7]

[Xiaolong Peng]

On Wed, 26 Jun 2024 17:26:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Okay. I don't understand the data in the third table for: `java -Xms256m -Xmx256m -XX:+UseShenandoahGC -XX:+UseTLAB -Xlog:gc -Xlog:safepoint Alloc.java`. Are those values also SP Polls? or are they GC counts? At any rate, isn't lower better? or did you chose 0xFF because it showed the best performance on dacapo testing?

These are GC counts I collected from gc log, run the same test code with command line java -Xms256m -Xmx256m -XX:+UseShenandoahGC -XX:+UseTLAB -Xlog:gc -Xlog:safepoint Alloc.java , with TLAB enabled, so they are close to real world cases.

Basically I was using GC count as a proxy of allocation rate, same test within same amount of time, more GCs counts, better throughput and performance. 

The test indicates less than 0xFF spin pauses causes regression in throughput except the designed test to mimic extreme contention we ran in the pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/19570#issuecomment-2192311250