RFR (M) 8198926: Move ClassLoaderData::_dependencies to ClassLoaderData::_handles

[Ioi Lam]

On 3/4/18 5:25 PM, coleen.phillimore at oracle.com wrote:
> Summary: Move dependency creation and cleaned up logging
>
> This change moves dependency creation to the ClassLoaderData::_handles 
> area so that it is scanned with _handles for GC.   The presence of the 
> dependency (either class loader or mirror for anonymous class), will 
> keep GC from unloading that dependency before unloading the 
> ClassLoaderData that has it. This replaces the objArrayOop field where 
> the array was populated with {dependency, next}.  Because the 
> objArrayOop could throw OOM while creation we needed to be careful 
> where it was called because it could call GC at inconvenient times, 
> and pass TRAPS.   A lot of this change removes the TRAPS parameter 
> from dependency and recording class loader data calls.
>
> The part of this change removes the redundant logging of 
> ClassLoaderData to call print_value_on, renames dump to print to 
> follow convention, and removes a call to Java to get toString() for 
> instances of class loader for logging.  The latter is unnecessary 
> since print_value_on() will print the address of the instance 
> (toString appends the hash number to the class name, ie. it's not more 
> informative), and this is a terrible place for an upcall to Java.
>
Hi Coleen,

I agree that the call to toString() can be removed from the logging. It 
was added by an experimental feature of AppCDS which has since been 
removed. So this call is no longer necessary.

Thanks
- Ioi
> Some of the logging is to verify that dependencies added are fairly 
> rare, since adding them are unnecessary for class loader parents (that 
> is through class loader delegation) or class loaders that are not 
> unloaded at all.   I verified this is true with daCapo and 
> SPECjbb2015, and runThese jck tests.
>
> Also tested performance with internal refworkload benchmarks, since 
> the original reason for the objArray was to use regular gc marking 
> when adding a dependency.  There was no decrease in performance, again 
> since these are rare.   The nice thing is if the number of 
> dependencies is zero there are less of these objarray[2] objects, 
> which were allocated eagerly one for each class loader.
>
> This was also tested with mach5 tier1-5 with no failures.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8198926.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8198926
>
> Thanks,
> Coleen