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

[coleen.phillimore at oracle.com]

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