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

[Thomas Schatzl]

Hi,

 first, let me say that I have not been involved in Ashley's discussion
with John, so these are only observations. Maybe other gc people know
more.

On Thu, 2013-07-11 at 16:42 +1000, David Holmes wrote:
> Hi Ashley,
> 
> Is this Dictionary the systemDictionary in the VM or something to do 

In this test program, the number of entries in the system dictionary
(SystemDictionary::number_of_classes()) grows steadily when using
Class.forName() when looking up "java.util.HashMap" in a loop; when
using the URLClassLoader instance to look up the same class, the size of
the system dictionary stays constant.

Only a full gc "fixes" the problem.

> with G1? If there is an issue with the VM's use of the systemDictionary 
> then it needs to be fixed in the VM. If there is an issue in G1 then it 
> needs to be fixed in G1. A change to the Java-level behaviour of 
> Class.forName needs to pass extreme scrutiny and as Ioi points out it is 
> not appropriate for forName to assume how a ClassLoader will load a 
> class - it must defer to the classloader to do it. So the patch is not 
> acceptable.
> 
> What exactly is G1 reporting and why do you think it is wrong? (I have 
> no idea what "Ext root scanning" means.)

Ext root scanning = "External root scanning" (I think :) time, i.e. an
estimate for the time finding the roots and determining whether they
should be changed take.

It does not include the time actual evacuation of any referenced object
takes.

This may e.g. be caused by increasing sizes of the VM internal data
structures, in this case the system dictionary.

hth,
  Thomas