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

[Jiangli Zhou]

Hi Coleen,

This looks good!

Thanks,
Jiangli

> On Mar 4, 2018, at 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.
> 
> 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