On Mon, 1 Jun 2026 16:24:48 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 incrementally with one additional > commit since the last revision: > > Address PR comments > > 1. The number of HTTP headers impacts the frame count but not the size > of the cached header buffer. Updated the comment to reflect this and > simplified the test to send just two follow-on requests: one with 2 > headers and another with 300 headers (to ensure that the cached > header buffer stays the same even when multiple frames are required). > > 2. Removed Markdown formatting from comments. > > 3. Fixed year in copyright notices. Thank you for the updates, this looks good to me. I'll run this change in our CI tomorrow and if the tests continue to pass, will approve it. Just as a final test of your own, you might want to make sure that the local JMH benchmark you had previously run continues to show reasonable improvements with this latest state of the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30931#issuecomment-4604682649
