RFR 7143743: (zipfs) Potential memory leak with zip provider

[Lance Andersen]

I am happy to sponsor this next week after providing time for additional review feedback and also sanity check it via Mach5

Best
Lance

> On Jan 11, 2020, at 5:24 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Hello Alan,
> 
> On 11/01/20 3:37 pm, Alan Bateman wrote:
>> On 11/01/2020 09:51, Jaikiran Pai wrote:
>>> :
>>> 
>>> The commit here fixes that issue by simply clearing the "inodes" map in
>>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage
>>> of the "inodes" map and from what I see, it's usage in various places is
>>> guarded by "ensureOpen" checks, which means that once the ZipFileSystem
>>> instance is closed, the contents of these "inodes" map is no longer
>>> relevant and hence clearing it shouldn't cause any issues.
>>> 
>> Clearing the inodes map should be okay for cases where something is
>> holding a reference to a closed zip file system. However, you should
>> look at beginWrite/endWrite so that all access to the map is
>> consistently synchronized.
>> 
> Thank you very much for that input - I hadn't considered the concurrency
> aspect of it. Based on your input and after looking at the usage of the
> "inodes", I have now updated the patch to use proper locks during the
> clearing of the inodes. The updated webrev is available at
> https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/ <https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/>
> 
> -Jaikiran

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>