Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8340814: ZipFileInflaterInputStream should release its Inflater after observing EOF #21157

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

eirbjo
Copy link
Contributor

@eirbjo eirbjo commented Sep 24, 2024

Please consider this PR which makes ZipFileInflaterInputStream release its Inflater instance back to the pool when observing that the stream has been fully consumed.

This is motivated by the following observations:

  • After a ZipFileInflaterInputStream has reached the end of stream, its Inflater instance no longer does useful work.
  • Obtaining an input stream via ZipFile::getInputStream without properly closing it is probably common. Obtaining it without fully consuming it is probably more rare. (Something like classLoader.getInputStream(entry).readAllBytes() is probably common)
  • While GC will eventually release the Inflater when the Cleaner closes the stream, this will only happen at some later point in time. In the meantime, ZipFile::getInputStream may produce many new Inflater instances. These will all be released to the pool once GC eventually catches up.
  • Once an Inflater is released to to pool, it will stay there for the lifetime of the ZipFile
  • The lifetime of a ZipFile may often be as long as the application (consider class loaders).

This PR suggests the following changes:

  • Rename the existing field ZipFileInflaterInputStream.eof to compressedEof. (This tracks the EOF of the filtered input stream)
  • Add a new field ZipFileInflaterInputStream.eof to track the EOF of uncompressed data.
  • Override ZipFileInflaterInputStream.read(byte[] b, int off, int len) to detect the EOF of uncompressed data and release the Inflater instance back to the pool when it is no longer needed.
  • To protect the Inflater instance from being used after being released and reset, the following updates are needed:
    • ZipFileInflaterInputStream.read must check if EOF has been reached but that the stream has not yet been closed. In this case, EOF should be returned.
    • Similarly, ZipFileInflaterInputStream.available needs an update to return 0 if EOF has been detected.

The PR adds a test ReleaseInflaterOnEOF which verifies that all fully consumed input streams are backed by the same Inflater instance.

This PR was inspired by JDK-7031076 and this discussion: https://mail.openjdk.org/pipermail/core-libs-dev/2011-March/006341.html


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8340814: ZipFileInflaterInputStream should release its Inflater after observing EOF (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21157/head:pull/21157
$ git checkout pull/21157

Update a local copy of the PR:
$ git checkout pull/21157
$ git pull https://git.openjdk.org/jdk.git pull/21157/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 21157

View PR using the GUI difftool:
$ git pr show -t 21157

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21157.diff

Webrev

Link to Webrev Comment

… observing that the stream is fully consumed (EOF)
@bridgekeeper
Copy link

bridgekeeper bot commented Sep 24, 2024

👋 Welcome back eirbjo! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Sep 24, 2024

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk
Copy link

openjdk bot commented Sep 24, 2024

@eirbjo The following label will be automatically applied to this pull request:

  • core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the core-libs core-libs-dev@openjdk.org label Sep 24, 2024
@eirbjo eirbjo marked this pull request as ready for review October 7, 2024 19:57
@openjdk openjdk bot added the rfr Pull request is ready for review label Oct 7, 2024
@mlbridge
Copy link

mlbridge bot commented Oct 7, 2024

Webrevs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org rfr Pull request is ready for review
Development

Successfully merging this pull request may close these issues.

1 participant