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
