Repository navigation
[CELEBORN-2500] Use ArrayDeque instead of LinkedList in TransportFrameDecoder - #3893
Closed
SteNicholas wants to merge 1 commit into
Closed
SteNicholas wants to merge 1 commit into
SteNicholas wants to merge 1 commit into
Conversation
…eDecoder Replace the pending input buffer queue with ArrayDeque. The decoder only uses FIFO operations, iteration, and clear, so frame decoding and buffer release semantics remain unchanged. LinkedList allocates a node for every incoming ByteBuf. ArrayDeque reuses its backing array, avoiding these per-read node allocations on the Netty receive path.
yew1eb
approved these changes
Oct 23, 2026
zaynt4606
pushed a commit
that referenced
this pull request
Oct 23, 2026
…eDecoder ### What changes were proposed in this pull request? Replace `LinkedList<ByteBuf>` with `ArrayDeque<ByteBuf>` for the pending input buffers in `TransportFrameDecoder`. The decoder assembles incoming buffers into complete frames before decoding messages. Buffers that have not yet been consumed are kept in a FIFO queue: `channelRead` appends at the tail, decoding reads and removes from the head, and `handlerRemoved` releases any remaining buffers before clearing the queue. `ArrayDeque` supports all operations used here (`add`, `getFirst`, `removeFirst`, iteration, and `clear`) with the same ordering. Frame assembly, buffer ownership, and reference-count release behavior remain unchanged. Backport: apache/spark#58857. ### Why are the changes needed? Each incoming `ByteBuf` currently causes `LinkedList.add` to allocate a separate list node. This adds allocation and garbage-collection work to the Netty receive path even when the buffer can be consumed immediately. `ArrayDeque` stores buffer references in a reusable backing array, removing the per-buffer list-node allocation while retaining efficient FIFO access. This is a small allocation optimization; its effect on end-to-end throughput has not been benchmarked. ### Does this PR resolve a correctness bug? - [ ] Yes ### Does this PR introduce _any_ user-facing change? - [ ] Yes No protocol, configuration, or API changes. ### How was this patch tested? Existing RPC integration tests passed on JDK 17: 7 tests in `RpcIntegrationSuiteJ` and 8 in `SSLRpcIntegrationSuiteJ`, with no failures or skipped tests. These exercise single and multiple RPCs, error responses, and one-way messages over plain and SSL connections. Closes #3893 from SteNicholas/CELEBORN-2500. Authored-by: Nicholas Jiang <programgeek@163.com> Signed-off-by: zhengtao <shuaizhentao.szt@alibaba-inc.com> AI-Contributed/Feature: 0/6 AI-Contributed/UT: 0/0 (cherry picked from commit 924b054) Signed-off-by: zhengtao <shuaizhentao.szt@alibaba-inc.com>
Contributor
Contributor
|
Thanks @SteNicholas for the contribution! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Replace
LinkedList<ByteBuf>withArrayDeque<ByteBuf>for the pending input buffers inTransportFrameDecoder.The decoder assembles incoming buffers into complete frames before decoding messages. Buffers that have not yet been consumed are kept in a FIFO queue:
channelReadappends at the tail, decoding reads and removes from the head, andhandlerRemovedreleases any remaining buffers before clearing the queue.ArrayDequesupports all operations used here (add,getFirst,removeFirst, iteration, andclear) with the same ordering. Frame assembly, buffer ownership, and reference-count release behavior remain unchanged.Backport: apache/spark#58857.
Why are the changes needed?
Each incoming
ByteBufcurrently causesLinkedList.addto allocate a separate list node. This adds allocation and garbage-collection work to the Netty receive path even when the buffer can be consumed immediately.ArrayDequestores buffer references in a reusable backing array, removing the per-buffer list-node allocation while retaining efficient FIFO access. This is a small allocation optimization; its effect on end-to-end throughput has not been benchmarked.Does this PR resolve a correctness bug?
Does this PR introduce any user-facing change?
No protocol, configuration, or API changes.
How was this patch tested?
Existing RPC integration tests passed on JDK 17: 7 tests in
RpcIntegrationSuiteJand 8 inSSLRpcIntegrationSuiteJ, with no failures or skipped tests. These exercise single and multiple RPCs, error responses, and one-way messages over plain and SSL connections.