-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P2
-
Affects Version/s: 21.0.9, 23, 25.0.1
-
Component/s: core-libs
-
b05
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8376348 | 26.0.1 | Paul Hohensee | P2 | Resolved | Fixed | b03 |
Read performance has degraded since JDK 23 in GZIPInputStream, after a change in JDK-7036144 causes an IOException to be thrown when checking for additional headers at the end of a stream. A common use case is to read single / one-shot compressed data streams from a byte array or from a socket, so the issue shows up in real world applications.
The specific code that is causing the performance regression is the one here that checks for the next header in the concatenated case: https://github.com/openjdk/jdk/blob/7c979c148724ab7de650593caa22df8405d740e5/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L261-L267
The specific code that is causing the performance regression is the one here that checks for the next header in the concatenated case: https://github.com/openjdk/jdk/blob/7c979c148724ab7de650593caa22df8405d740e5/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L261-L267
- backported by
-
JDK-8376348 Regression in GZIPInputStream performance after JDK-7036144
-
- Resolved
-
- caused by
-
JDK-7036144 GZIPInputStream readTrailer uses faulty available() test for end-of-stream
-
- Closed
-
- links to
-
Commit(master)
openjdk/jdk26u/119cf369
-
Commit(master)
openjdk/jdk/a4fb07ee
-
Review(master)
openjdk/jdk25u-dev/139
-
Review(master)
openjdk/jdk26u/12
-
Review(master)
openjdk/jdk/29092
(2 links to)