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

Hi, Looks good to me 😊 Cheers Christoph From: Lance Andersen Sent: Montag, 13. Januar 2020 21:26 To: Alan Bateman Cc: Jaikiran Pai ; Langer, Christoph ; nio-...@openjdk.java.net; core-libs-dev@openjdk.java.net Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider On

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

Looks fine Lance. I forgot about the copyright year, thank you for taking care of that one too. -Jaikiran On 14/01/20 1:56 am, Lance Andersen wrote: > > >> On Jan 13, 2020, at 1:53 PM, Alan Bateman > > wrote: >> >> On 13/01/2020 10:31, Jaikiran Pai wrote: >>> Hello

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

> On Jan 13, 2020, at 1:53 PM, Alan Bateman wrote: > > On 13/01/2020 10:31, Jaikiran Pai wrote: >> Hello Christoph, >> >> Setting inodes to null sounds fine to me and as you say since its usage >> is already guarded by ensureOpen, IMO, it should be fine. I've now >> updated the patch to set i

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

On 13/01/2020 10:31, Jaikiran Pai wrote: Hello Christoph, Setting inodes to null sounds fine to me and as you say since its usage is already guarded by ensureOpen, IMO, it should be fine. I've now updated the patch to set inodes to null in close() and the new updated webrev is at https://cr.open

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

dk.java.net >> Cc: core-libs-dev@openjdk.java.net >> Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider >> >> Hello Alan, >> >> On 11/01/20 3:37 pm, Alan Bateman wrote: >>> On 11/01/2020 09:51, Jaikiran Pai wrote: >>>> : >>

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

oph > -Original Message- > From: nio-dev On Behalf Of Jaikiran > Pai > Sent: Samstag, 11. Januar 2020 11:24 > To: Alan Bateman ; nio-...@openjdk.java.net > Cc: core-libs-dev@openjdk.java.net > Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider >

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

Thank you Lance. -Jaikiran On 12/01/20 2:26 am, Lance Andersen wrote: > 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 >

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

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 wrote: > > Hello Alan, > > On 11/01/20 3:37 pm, Alan Bateman wrote: >> On 11/01/2020 09:51, Jaikiran Pai wrote: >>

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

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,

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

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, whi

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

Can I please get a review and a sponsor for a patch which fixes JDK-7143743[1]? The patch is hosted as a webrev at [2]. As noted in the JBS issue, the ZipFileSystem, even after being closed can end up holding on to large amounts of memory. The root of the issue is the "inodes" map which is maintai