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