yandrey321 opened a new pull request, #11147:
URL: https://github.com/apache/ozone/pull/11147
## What changes were proposed in this pull request?
### Problem
ChunkBuffer exposes put(byte[]) and put(byte[], int, int) as interface
default methods that wrap the array in a throwaway buffer and delegate to
put(ByteBuffer):
```
default ChunkBuffer put(byte[] b) {
return put(ByteBuffer.wrap(b));
}
default ChunkBuffer put(byte[] b, int offset, int length) {
return put(ByteBuffer.wrap(b, offset, length));
}
```
Every put(byte[]) on the chunk-write path therefore allocates a short-lived
HeapByteBuffer wrapper purely to hand the bytes to the destination buffer. On
the hot write path this is per-call garbage that the copy itself does not need.
### Change
Override put(byte[]) / put(byte[], int, int) in all three ChunkBuffer
implementations so the array is copied directly into the backing ByteBuffer(s)
via ByteBuffer.put(byte[], int, int), with no intermediate wrap:
ChunkBufferImplWithByteBuffer (single backing buffer) — buffer.put(b,
offset, length).
ChunkBufferImplWithByteBufferList (fixed buffer list) — fills successive
current() buffers until the range is consumed.
IncrementalChunkBuffer (allocate-on-demand) — fills successive buffers,
allocating at position as needed.
The interface defaults are kept as a fallback for any other/foreign
implementation, so behavior is unchanged for callers that don't hit these three
concrete types.
Generated-by: Claude Code (Opus 4.8)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-15485
## How was this patch tested?
CI:
- TestChunkBuffer — added coverage for put(byte[]) and put(byte[], int, int)
across the single-buffer, buffer-list, and incremental implementations,
including multi-buffer-spanning ranges and the bounds/overflow error paths.
- ChunkBufferPutBenchmark + JfrByteBufferAllocations (JFR profiler), 4KB
stream-fill into a 64KB-increment IncrementalChunkBuffer (the targeted hot
path):
### Allocation elimination — the goal of this change:
Direct put(byte[]): 0 ByteBuffer.wrap calls and 0 ByteBuffer allocations —
JFR confirms zero ByteBuffer TLAB allocations on this path.
Previous wrap path: 49,430,528 ByteBuffer.wrap allocations per run (one
throwaway HeapByteBuffer per put).
Net: ~49.4M wrapper allocations per run removed — a 100% reduction on this
path, cutting exactly that much per-write garbage off the chunk-write hot path
and the GC pressure it creates under concurrent load.
No throughput cost: ~38 GB/s and ~102 ns/op on both paths across 3 rounds
(within run-to-run noise) — the allocation savings come at no measurable
performance penalty.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
