RFR: 8308231: Faster MemAllocator::Allocation checks for verify/notification

Aleksey Shipilev shade at openjdk.org
Wed May 17 11:59:41 UTC 2023


In multi-array allocations benchmarks, there is a hot path through the native VM allocation code, which calls lots of notification methods, even when we would return immediately, because the allocation was satisfied from existing TLAB. Not calling these helper methods from `MemAllocator::Allocation` constructor/destructor looks like an incremental win for the benchmarks.

Example on M1:


Benchmark             (size)  Mode  Cnt        Score        Error  Units

# Before
MultiArrayAlloc.full       1  avgt   15       74,053 ±      0,869  ns/op
MultiArrayAlloc.full       2  avgt   15       87,800 ±      0,931  ns/op
MultiArrayAlloc.full       4  avgt   15      124,814 ±      0,615  ns/op
MultiArrayAlloc.full       8  avgt   15      188,562 ±      0,785  ns/op
MultiArrayAlloc.full      16  avgt   15      313,007 ±      1,108  ns/op
MultiArrayAlloc.full      32  avgt   15      640,276 ±      4,560  ns/op
MultiArrayAlloc.full      64  avgt   15     1395,220 ±      5,860  ns/op
MultiArrayAlloc.full     128  avgt   15     3417,848 ±     11,345  ns/op
MultiArrayAlloc.full     256  avgt   15     9955,360 ±    102,057  ns/op
MultiArrayAlloc.full     512  avgt   15    27738,002 ±    244,940  ns/op
MultiArrayAlloc.full    1024  avgt   15   147507,008 ±   1434,085  ns/op

# After
MultiArrayAlloc.full       1  avgt   15       70,434 ±      0,373  ns/op  ;  5% better
MultiArrayAlloc.full       2  avgt   15       82,394 ±      0,137  ns/op  ;  7% better
MultiArrayAlloc.full       4  avgt   15      108,542 ±      0,129  ns/op  ; 15% better
MultiArrayAlloc.full       8  avgt   15      170,697 ±      4,480  ns/op  ; 11% better
MultiArrayAlloc.full      16  avgt   15      272,902 ±      0,877  ns/op  ; 15% better
MultiArrayAlloc.full      32  avgt   15      524,486 ±      1,447  ns/op  ; 22% better
MultiArrayAlloc.full      64  avgt   15     1088,932 ±      2,739  ns/op  ; 17% better
MultiArrayAlloc.full     128  avgt   15     3151,144 ±     14,621  ns/op  ;  8% better
MultiArrayAlloc.full     256  avgt   15     8455,293 ±     12,656  ns/op  ; 18% better
MultiArrayAlloc.full     512  avgt   15    26060,055 ±    116,524  ns/op  ;  6% better
MultiArrayAlloc.full    1024  avgt   15   130824,480 ±    831,703  ns/op  ; 13% better


Additional testing:
 - [x] Ad-hoc micro-benchmarks
 - [x] Linux x86_64 fastdebug `serviceability/jvmti`
 - [x] Linux x86_64 fastdebug `jdk/jfr`
 - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`
 - [x] Linux AArch64 fastdebug `tier1 tier2 tier3`

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

Commit messages:
 - Hide more stuff
 - Touchups
 - Branch
 - Fix

Changes: https://git.openjdk.org/jdk/pull/14019/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14019&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308231
  Stats: 29 lines in 1 file changed: 20 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14019.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14019/head:pull/14019

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


More information about the hotspot-gc-dev mailing list