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

[coleen.phillimore at oracle.com]

On 3/5/18 2:58 PM, Ioi Lam wrote:
>
>
> 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 for the explanation!
Coleen

>
> 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
>