On Mon, 23 Feb 2026 11:46:29 GMT, Peter Levart <[email protected]> wrote:
>> Hi, >> >> When administering my mailing lists, my attention was drawn to this pull >> request: https://github.com/openjdk/jdk/pull/28575, which tries to tackle >> this scaling problem. Although it was dismissed, I remembered that I was >> dealing with a similar problem in the past, so I looked closely... >> >> Here's an alternative take at the problem. It reuses a maintained public >> component of JDK, the LongAdder, so in this respect, it does not add >> complexity and maintainance burden. It also does not change the internal API >> of the MemorySessionImpl. The size of the patch is also smaller. >> >> For experimenting and benchmarking, I created a separate impmenetation of >> just the acquire/release/close logic with existing "simple" and this new >> "striped" implementations here: >> >> https://github.com/plevart/acquire-release-close >> >> Running it on my 8 core (16 threads) Linux PC, it gives promising results >> without regression for single-threaded use: >> >> >> ** Simple, measure run #1... >> concurrency: 1, nanos: 39909697 (x 1.0) >> concurrency: 2, nanos: 164735444 (x 4.127704702944751) >> concurrency: 4, nanos: 394283724 (x 9.87939657873123) >> concurrency: 8, nanos: 672278915 (x 16.84500172978011) >> concurrency: 16, nanos: 2169282886 (x 54.3547821473062) >> ** Simple, measure run #2... >> concurrency: 1, nanos: 40318379 (x 1.0) >> concurrency: 2, nanos: 163438657 (x 4.053701092496799) >> concurrency: 4, nanos: 399382210 (x 9.905710991009832) >> concurrency: 8, nanos: 694862623 (x 17.23438888750959) >> concurrency: 16, nanos: 2182386494 (x 54.12882531810121) >> ** Simple, measure run #3... >> concurrency: 1, nanos: 39871197 (x 1.0) >> concurrency: 2, nanos: 168843686 (x 4.234728292707139) >> concurrency: 4, nanos: 375489497 (x 9.417562683156966) >> concurrency: 8, nanos: 675885694 (x 16.951728186138983) >> concurrency: 16, nanos: 2083500812 (x 52.255787856080666) >> ** end. >> >> ** Striped, measure run #1... >> concurrency: 1, nanos: 36698350 (x 1.0) >> concurrency: 2, nanos: 47349695 (x 1.290240433152989) >> concurrency: 4, nanos: 58622304 (x 1.5974098018030782) >> concurrency: 8, nanos: 60548173 (x 1.6498881557345222) >> concurrency: 16, nanos: 70607406 (x 1.9239940215295783) >> ** Striped, measure run #2... >> concurrency: 1, nanos: 37217044 (x 1.0) >> concurrency: 2, nanos: 38610020 (x 1.0374284427317764) >> concurrency: 4, nanos: 39166893 (x 1.0523912914738742) >> concurrency: 8, nanos: 51778829 (x 1.3912665659314587) >> concurrency: 16, nanos: 70277394 (x 1.8883120862581133) >> ** Striped, measu... > > Peter Levart has updated the pull request incrementally with one additional > commit since the last revision: > > 8371260: Fix wrong VarHandle usage, remove unneeded fullFence from > justClose() The single-threaded regression for ARM (and a little also for Intel) is probably caused by fullFence in SharedSession.acquire0. This is necessary to prevent theoretical (and in ARM case probably also practical) reordering as described in the comments. The fullFence would not be necessary if LongAdder was using normal CAS instead of weak CAS (in Striped64): final boolean casBase(long cmp, long val) { return BASE.weakCompareAndSetRelease(this, cmp, val); } and @jdk.internal.vm.annotation.Contended static final class Cell { volatile long value; Cell(long x) { value = x; } final boolean cas(long cmp, long val) { return VALUE.weakCompareAndSetRelease(this, cmp, val); } In this case, a volatile read of an unrelated variable following this CAS could not be reordered with the CAS. But as LongAdder was not designed to be used in such situations, it is unfortunately using weak CAS. It still can be used as such with additional fullFence, so it is fine as long as it is not compared with (non-scalable) solution that uses normal CAS. Idea: We could add LongAdder.addVolatile method (possibly package-private and exposed internally via SharedSecrets) which would use normal CAS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29866#issuecomment-4165262263
