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

Martin Buchholz martinrb at google.com
Mon May 23 19:21:06 UTC 2016


On Mon, May 23, 2016 at 11:28 AM, Xueming Shen <xueming.shen at oracle.com> wrote:

> The proposed change switches from the finalizer to the ObjectPool to clean
> up
> the native resource for Inflater. It appears to be a bigger change. Which
> has
> a default 32/maxCacheSize and 1 secod keepAliveTime setting. It might have
> a big impact to existing applications on how to use the Inflater. It would
> be
> fine to have the ZipFile to arrange how to use the Inflater based on its use
> scenario, but I'm concerned if it's the correct approach to change the
> default
> behavior of Inflater, which might have nothing to do with ZipFile.

This _is_ becoming a big scary change, but getting rid of the rat's
nest of finalizers is definitely progress.

I am still contending that zstream caching is not worth much.  The
best I could do with a synthetic benchmark designed to make caching
win was 25% better performance.  Martin's rule is if you can't even
come up with a friendly benchmark that gives you a 2x win, give up on
your optimization!  So performance wise, there is no big impact here
on any applications, except to fix excessive memory retention and
OOME.

(but yeah, it's barely worth maintaining a cache, because this code is
so performance critical)



More information about the core-libs-dev mailing list