RFR: 8156484: ZipFile retains too much native memory from caching Inflaters
Peter Levart
peter.levart at gmail.com
Fri May 20 06:25:24 UTC 2016
Hi Martin,
On 05/20/2016 12:04 AM, Martin Buchholz wrote:
> Hi Peter,
>
> I would make e.g. the change to Resource an independent change.
I agree. It's just that if we measure the impact of ZipFile changes to
class loading, for example, we should measure them with this change
included so that we get the optimal caching strategy implemented. After
we settle on the ZipFile changes, we can strip-off this independent
change and propose it separately.
>
> Below you declare that you throw IOException, but you actually swallow
> it, which is not good.
>
> /**
> + * Closes cached input stream used for getBytes / getByteBuffer
> + * @throws IOException
> + */
> + @Override
> + public synchronized void close() {
Yes, I forgot to remove the @throws. I think it is OK to swallow the
IOException here, as what is currently done, when the input stream(s)
are finalized, such IOException(s) are ignored (if they ever get
thrown). It's also nothing we can do here since this exception would get
thrown after the class has already been defined and we can't propagate
the exception or unsuccessful class loading result to the caller after
successfully defining the class.
Regards, Peter
More information about the core-libs-dev
mailing list