RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can result in large TTSP spikes [v2]

Rohitash Kumar duke at openjdk.org
Wed May 28 12:46:38 UTC 2025


> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> I added a benchmark for potential perf regression, following are the results.
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        860.869 ±     170.921  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1368.599 ±     320.159  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80169.230 ±     448.075  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  635047372.458 ± 5461328.161  ns/op
> 
> **After**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         128  avgt   25        869.676 ±     160.633  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer        1024  avgt   25       1328.623 ±     282.198  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer     1048576  avgt   25      80224.157 ±     454.906  ns/op
> ByteBufferAllocationBenchmark.allocateDirectBuffer  2147483647  avgt   25  667037308.198 ± 4818648.535  ns/op

Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:

  update license and stylistic improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/3aa67da1..03567436

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

  Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25487/head:pull/25487

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


More information about the nio-dev mailing list