Yes! Good catch, thanks.
-Brent
On 10/5/16 2:08 PM, Naoto Sato wrote:
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
