AFAIK, "Win32ShellFolder2.listDrives()" returns an array of File objects. Now,
once the function "isFileSystemRoot" is exited, the Array will get destroyed,
but the object references will be cleaned up by GC, whenever it runs. The
problem is if we repeatedly call "isFileSystemRoot" function, it will keep
creating those objects, and might overwhelm the memory, before GC gets a chance
to run. I have even seen that in some cases, the available memory increases,
which indicates that GC has performed some cleanup.
Pasting below an excerpt of the log of memory consumption as mentioned in the
6.4 % (3175/50000) [Memory Used: 15,872 kb Free=1,030 kb Max: 15,872 kb]
6.5 % (3225/50000) [Memory Used: 15,872 kb Free=796 kb Max: 15,872 kb]
6.6 % (3275/50000) [Memory Used: 15,872 kb Free=2,185 kb Max: 15,872 kb]
6.7 % (3325/50000) [Memory Used: 15,872 kb Free=1,940 kb Max: 15,872 kb]
6.8 % (3375/50000) [Memory Used: 15,872 kb Free=1,661 kb Max: 15,872 kb]
In line 1, the free memory is 1030kb, which reduces to 796kb, but in line 3, it
increases to 2185 kb, which indicates that GC had a chance to cleanup some
memory. After that, it is again reducing. You can see that this kind of pattern
repeats a few times, but eventually, the memory runs out.
From: Sergey Bylokhov
Sent: Wednesday, August 9, 2017 5:16 AM
To: Krishna Addepalli <krishna.addepa...@oracle.com>; firstname.lastname@example.org
Subject: Re: <AWT Dev> [JDK-8175015] FileSystemView.isDrive(File) memory
leak on "C:\" file reference
Hi, Krishna.> The problem is internally, Win32ShellFolderManager2.java, the
> "isFileSystemRoot" is called, which lists the contents of all the root
> drives, in addition to including them. It also includes the hidden
> files. For each file present, it is wrapped with a "Win32ShellFolder2"
> object. So, for each query, it will list the files in the drives, and
> throws them away, which is leading to both memory consumption as well
> as slow performance.
If for each query we list the files in the drive and *throws* all of them away,
then why(and where) we have a memory leak and as a result OOM.
Best regards, Sergey.