G1 garbage collection Ext Root Scanning time increases due to Class.forName (Problem, Solution, and Patch)

[Ioi Lam]

|Hi Ashley,||
||
||Thanks for submitting the patch. One issue with the patch is ||that it 
assumes||
||all ClassLoaders will delegate to ||the parent loader first.

However, there||||is no such requirement in the Java API. E.g., a 
ClassLoader may
decide to||||search its own JAR files first||, before calling the parent's
loadClass() method.|

Here's an example: http://tech.puredanger.com/2006/11/09/classloader/

Such loaders would be broken by this patch.

|- Ioi|

|--------------------------------------------------------------------------------
diff -r cfd7602f5c52 src/share/classes/java/lang/Class.java|
|||+        private static Class<?> forNameInner(String name, boolean 
initialize,|
|+ ClassLoader loader)|
|+        throws ClassNotFoundException|
|+    {|
|+        //same recursive pattern found in ClassLoader.loadClass|
|+       Class c = null;|
|+       if(loader != null){|
|+           //if we have a parent classloader check that one first.|
|+           ClassLoader parent = loader.getParent();|
|+           try {|
|+                 if (parent != null) {|
|+                     c = forNameInner(name, initialize, parent);|
|+                 }|
|+             } catch (ClassNotFoundException e) {|
|+                 // ClassNotFoundException thrown if class not found|
|+                 // from the non-null parent class loader|
|+             }|
|+         }|
|+        if (c == null) {|
|+            c = forName0(name, initialize, loader);|
|+        }|
|+        return c;|
|+    }|
|--------------------------------------------------------------------------------
|

On 07/09/2013 03:17 PM, Ashley Taylor wrote:
>
> Hello
>
> We have an application that makes heavy use of an apache API that uses 
> Class.forName.
>
> Using this method call wehave noticed is that over time the "Ext Root 
> Scanning" aspect of the G1 garbage collector time increased linearly.
>
> Working with John Cuthbertson from the hotspot-gc mailing list we 
> tracked this down to the Dictionary thread within the garbage collector.
>
> https://www.dropbox.com/s/7s7gishn8mxtote/G1Checker.java reproduces 
> this issue, to see the issue run it with the following jvm options
>
> -XX:+PrintGCDetails -XX:+UseG1GC
>
> Watch the Ext Root Scanning time and a single thread will start to climb.
>
> We propose that when loading a class in a new classloader using 
> Class.forName it will create a reference in the Dictionary table even 
> when the class is present in the Dictionary table due to a parent 
> classloader.
>
> We have created a patch 
> https://www.dropbox.com/s/t7gepqsvksz77kv/Class.diff to the 
> Class.forName method that fixes this bug by using the same approach as 
> UrlClassLoader.loadClass
>
> which recursively tries to load the given class in its parent 
> classloader first.
>
> The only potential change in behaviour that we could imagine is to how 
> static objects within the class get referenced,
>
> have creating some unit tests have confirmed that the behaviour is 
> identical after the patch.
>
> https://www.dropbox.com/s/wf8rfa53jl7o5zg/ClassLoaderTests.java
>
> https://www.dropbox.com/s/y5ir6x927niu2ax/Loaded.java
>
> We have been using this patch in production now for the last couple of 
> month with no issues and would like to see it adopted so we can stop 
> using a custom build.
>
> Cheers,
>
> *Ashley Taylor*
>
> Software Engineer
>
> Email:ashley.taylor at sli-systems.com <mailto:ashley.taylor at sli-systems.com>
>
> Website: www.sli-systems.com <http://www.sli-systems.com/>
>
> Blog: blog.sli-systems.com <http://blog.sli-systems.com/>
>
> Podcast: EcommercePodcast.com <http://ecommercepodcast.com/>
>
> Twitter: www.twitter.com/slisystems <http://www.twitter.com/slisystems>
>
> sli_logo_2011**
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130710/2944d166/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8602 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130710/2944d166/attachment-0001.png