RFR 8151486 : Class.forName causes memory leak

Brent Christian brent.christian at oracle.com
Wed Oct 5 19:38:10 UTC 2016


Please review my fix for 8151486, "Class.forName causes memory leak".


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 

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 

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 

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.


More information about the core-libs-dev mailing list