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 <[email protected]>
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
