Regression in GZIPInputStream performance since JDK 23

[Patrick Strawderman]

Wanted to discuss a performance regression I noticed here before opening an
issue since I'm somewhat surprised it's flown under the radar and wanted a
gut check.

In an application that does GZIP decoding from byte[] per request, I
noticed in a profile that these calls were spending a lot of time in
Throwable#fill_in_stack_trace, something I hadn't seen before. I found
JDK-7036144
[1], and looking into the change I see that when decoding a single GZIP
message we now rely on exceptions for control flow to detect the end of
input, which is likely the cause. I wrote a JMH benchmark [2] and tested
performance between JDK 22 and 23+ and the performance seems much worse for
this single-shot use case, which I suspect is fairly common when
decompressing bytes off the wire. Running the benchmark locally I see
20-30% reduction in throughput.

Wanted to check if this is a known issue or if I am just missing something.

Thanks,
Patrick Strawderman

[1]
https://github.com/openjdk/jdk/commit/d3f3011d56267360d65841da3550eca79cf1575b
[2] https://gist.github.com/kilink/9a9bed0a8a272d9b8826d5c49f1708a4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260106/1f380f85/attachment-0001.htm>