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

[Rohitash Kumar]

> 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.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

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

  make chunk_size a constant

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

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

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

  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 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