On Fri, 24 Apr 2026 22:02:15 GMT, Ashay Rane <[email protected]> wrote:
>> Prior to this patch, every HTTP request created a new 16KB buffer for >> encoding the header, which is typically only a few hundred bytes long. >> This increased pressure on the garbage collector when the client created >> lots of requests. This patch instead makes the header encoder reuse the >> buffer that is created during the handling of the first request. >> >> The caveat, however, is that the downstream consumers of the header are >> asynchronous, so the encoder needs to take special care to ensure that >> it doesn't modify or invalidate the buffer after it hands the buffer >> over to the downstream asynchronous pipeline. To resolve this, this >> patch snapshots the buffer data into compact copies sized to the actual >> encoded length. Doing so makes the buffer immediately available for >> reuse via `clear()` and `limit()`. >> >> For typical requests, this reduces per-request allocation from 16KB to >> a few hundred bytes (i.e. the size of the compact copy of the encoded >> headers), with the 16KB encoding buffer allocated once per connection >> instead of once per request. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Ashay Rane has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains two additional commits since > the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into > JDK-8383248-reuse-buffer-in-header-encoding > - Reuse buffer for encoding headers instead of allocating one per request > > Prior to this patch, every HTTP request created a new 16KB buffer for > encoding the header, which are typically only a few hundred bytes long. > This increased pressure on the garbage collector when the client created > lots of requests. This patch instead makes the header encoder reuse the > buffer that is created during the handling of the first request. > > The caveat, however, is that the downstream consumers of the header are > asynchronous, so the encoder needs to take special care to ensure that > it doesn't modify or invalidate the buffer after it hands the buffer > over to the downstream asynchronous pipeline. To resolve this, this > patch snapshots the buffer data into compact copies sized to the actual > encoded length. Doing so makes the buffer immediately available for > reuse via `clear()` and `limit()`. > > For typical requests, this reduces per-request allocation from ~16KB to > a few hundred bytes (i.e. the size of the compact copy of the encoded > headers), with the 16KB encoding buffer allocated once per connection > instead of once per request. Thank you for running the additional JMH benchmarks yourself. Those do show good improvements with the proposed changes in this PR. Looking at the JMH benchmark that is made availbale in a comment in this PR https://github.com/openjdk/jdk/pull/30931#issuecomment-4330459981, was a LLM tool used to generate it? Some parts of it give me that impression, but it's hard to detect these details and I might be wrong, so please do correct me if that's not the case. If an LLM was indeed used to generate it, then I'll have to check with others if it still follows the OpenJDK guidelines https://openjdk.org/legal/ai. The JMH benchmark isn't being proposed as a contribution in this PR, so I don't know if it still complies with the FAQ#5 in those guidelines and whether it's OK to go ahead with this PR review and subsequent integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30931#issuecomment-4333225870
