RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas, take 2 [v2]

[Peter Levart]

> 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, measure run #3...
> concurrency: 1, nanos: 37589735 (x 1.0)
> concurrency: 2, nanos: 38748261 (x 1.03...

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  8371260: Prevent two theoretical reorderings of volatile write beyond volatile read

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29866/files
  - new: https://git.openjdk.org/jdk/pull/29866/files/fa88fcca..bced1b62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=00-01

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29866/head:pull/29866

PR: https://git.openjdk.org/jdk/pull/29866