RFR 8151486 : Class.forName causes memory leak

[Naoto Sato]

Typo in ClassForNameLeak.java? At line 103, "change" -> "chance"?

Naoto

On 10/5/16 12:38 PM, Brent Christian wrote:
> Hi,
>
> Please review my fix for 8151486, "Class.forName causes memory leak".
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8151486
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8151486/webrev.00/
>
> The test case reproduces the bug as such:
>
> With a SecurityManager enabled, a class ("ClassForName") is loaded from
> a user classloader (isa URLClassLoader, "LeakedClassLoader"), and from
> that class makes a call to Class.forName() on the system classloader.
> (The specific class name isn't so important, I just used
> java.util.List).  The result is that the user's classloader is never
> collected.
>
> The leak occurs because of the following:
>
> Class.forName0() is passed the "caller" class, ClassForName.
>
> JVM_FindClassFromCaller will "find a class with this name
> (java.util.List) in this loader (the system classloader), using the
> caller's (ClassForName's) protection domain.  A ProtectionDomain is
> created for ClassForName, with ProtectionDomain.classloader referring to
> LeakedClassLoader.
>
> This PD is passed to ClassLoader.checkPackageAccess(), and is added to
> 'domains' of the system classloader (ClassLoader.java line 643).  Thus,
> the system classloader holds a reference to the user's classloader via
> 'domains'.
>
> Nothing is ever removed from 'domains'.  In fact, besides being added
> to, I found no other uses of 'domains' - not in library code, not in
> hotspot.  (From my research, it's questionable if 'domains' was ever used).
>
> Removal of 'domains' fixes the leak, and cleans out a little bit of
> unused code.
>
> Automated building and testing (JPRT, RBT) looks fine.
>
> Thanks!
> -Brent
>