Regression in GZIPInputStream performance since JDK 23

[Jaikiran Pai]

Thank you Patrick for reporting this, providing the JMH benchmark and 
also narrowing this down to the actual root cause of the performance 
regression. A PR addressing this regression has been proposed 
https://github.com/openjdk/jdk/pull/29092 and with those changes the JMH 
benchmark numbers are back to the JDK 22 levels (the one without the 
JDK-7036144 change).

If you have built the JDK project before and are interested in trying 
out that proposed change, then it would be good to verify that PR 
against your actual application too. Furthermore, if the 
library/application which exposed this problem is public and easy to 
build, then it would be good to know where it resides - that might help 
us run some experiments whenever there are future changes in this area.

-Jaikiran

On 07/01/26 3:55 am, Patrick Strawderman wrote:
> I've created an issue to track this here: 
> https://bugs.openjdk.org/browse/JDK-8374644
>
> On Tue, Jan 6, 2026 at 11:29 AM Alan Bateman <alan.bateman at oracle.com> 
> wrote:
>
>
>
>     On 06/01/2026 17:19, Patrick Strawderman wrote:
>>     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 think you're right, the read of the next header could handle end
>     of stream to avoid the ZipException. We should create an issue in
>     JBS to look at this.
>
>     -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260107/b4927bd1/attachment-0001.htm>