Reuse sigv4 chunk buffer - #7219
Open
RanVaknin wants to merge 3 commits into
Open
Conversation
RanVaknin
marked this pull request as ready for review
August 3, 2026 22:31
|
This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Benchmark
The new
Sigv4ChunkedSigningBenchmarksigns and fully consumes an in memory S3PUTpayload (excluding network so that SDK signing and encoding costs remain narrow and accurate). It covers 64 KiB, 1 MiB, and 16 MiB payloads across signed payload, signed checksum trailer, and unsigned checksum trailer modes; these cases exercise the important variations while showing how costs scale with payload size.Finding and fix
JFR showed that
ChunkedEncodedInputStream.getChunkaccounted for 51%-74% of self CPU and 88%-100% of sampled allocation weight in the useful profiles. The implementation allocated a new 128 KiB array for every chunk and another array when probing for EOF, so a 16 MiB request allocated roughly 16 MiB of temporary chunk arrays even though only one chunk is consumed at a time.This optimization target changes
core/http-auth-awsatsoftware.amazon.awssdk.http.auth.aws.internal.signer.chunkedencoding.ChunkedEncodedInputStreamto lazily allocates one chunk array per stream, refills it only after the previous chunk is exhausted, and releases it at EOF, read failure, or close.From a customer perspective there is no new API or behavior. Synchronous S3 customers using
aws-chunkeduploads benefit through lower allocation pressure and less CPU spent allocating and zeroing arrays, with the largest effect on large payloads and unsigned checksum trailer uploads where cryptographic work does not dominate.Results
Before (64KiB unsigned trailer case)
CPU:

Memory:

After (64KiB unsigned trailer case)
CPU:

Memory:
The final comparison used Amazon Corretto 17 on the same dedicated host for baseline and candidate, with JMH
-wi 5 -i 5 -f 2 -prof gc.