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