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