> 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 four additional commits since
the last revision:
- Address PR suggestions
1. Added an assertion to check whether sendlock is held by the current
thread.
2. Replaced lambda (`captureAndAddtoBuffers`) with a private static
method (`copyBuffer`) since the lambda doesn't really save us any
significant lines of code.
3. Used `${test.main.class}` instead of explicitly spelling out the
class name.
4. Used junit instead of JDK test library assertions, updated the rest
of the test accordingly.
5. Used `HttpTestServer` and `URIBuilder` in the test, dropped the
initial warmup since the HTTP version is "2" by construction.
6. Used junit's `assertSame` method for ensuring that the connection
object and the cache header buffer are the same across various
`send()` invocations.
7. Minor fixes (updated copyright year and comments)
- Merge branch 'master' into JDK-8383248-reuse-buffer-in-header-encoding
- 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.
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/30931/files
- new: https://git.openjdk.org/jdk/pull/30931/files/a59c91b3..11f84d5b
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=30931&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=30931&range=01-02
Stats: 56091 lines in 335 files changed: 3279 ins; 52235 del; 577 mod
Patch: https://git.openjdk.org/jdk/pull/30931.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/30931/head:pull/30931
PR: https://git.openjdk.org/jdk/pull/30931
