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

[harold seigel]

Hi Coleen,

These changes look good.  Thanks for simplifying the dependency recording.

Harold


On 3/4/2018 8: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