RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

Martin Buchholz martinrb at google.com
Thu May 19 15:00:45 UTC 2016


On Thu, May 19, 2016 at 7:29 AM, Peter Levart <peter.levart at gmail.com> wrote:
> But I have reservation for the implementation of one-element global cache of
> Inflater. This cache can't be efficient. In order for cache to be efficient,
> majority of calls to ZipFile.getInputStream(zipEntry) would have to be
> accompanied by a corresponding explicit close() for the input stream before
> the WeakReference to the cached Inflater is cleared.

That's my assumption.  In most cases, failure to close something that
can be closed is a bug.
If there's code in the JDK that fails to do that, it should be fixed
independently.

> The "assert !inf.ended()" in
> releaseInflater() can therefore fail as final() methods on individual
> objects that are eligible for finalization may be invoked in arbitrary
> order.

Yeah, that's a bug. We can only assert after we verify that the
Inflater is still weakly reachable.
Updating my webrev with:

      * Releases the Inflater for possible later reuse.
      */
     private static void releaseInflater(Inflater inf) {
-        assert !inf.ended();
         CachedInflater cachedInflater = inflaterCache.get();
         if (inf != cachedInflater.get()) {
             inf.end();
         } else {
             // "return" the Inflater to the "pool".
+            assert !inf.ended();
             inf.reset();
             assert cachedInflater.inUse.get();
             cachedInflater.inUse.set(false);



More information about the core-libs-dev mailing list