RFR (M) JDK-8202605: Standardize on ClassLoaderData::loader_name() throughout the VM to obtain a class loader's name

[Lois Foltan]

On 6/14/2018 6:23 PM, mandy chung wrote:
> On 6/14/18 2:28 PM, Lois Foltan wrote:
>> It was intentional, I did change
>> classfile/classLoaderHierarchyDCmd.cpp to output the class loader's
>> name_and_id, thus causing differing results for the test.  Like jcmd
>> do you think name_and_id is not applicable here as well?
> I wasn't aware that classfile/classLoaderHierarchyDCmd.cpp is for jcmd 
> to use (the file does say so but I was assuming that dcmd source files 
> would be in other directory).
>
> The test comment does not indicate the oop pointer address is printed
Hi Mandy,
I will update the test comment.

> but I notice that the jcmd output Thomas sent out earlier.  I confirm 
> from the implementation:
>
>  162     // e.g. "+--- jdk.internal.reflect.DelegatingClassLoader"
>  163     st->print("+%.*s", BranchTracker::twig_len, "----------");
>  164     st->print(" %s,", _cld->loader_name_and_id());
>  165     if (!_cld->is_the_null_class_loader_data()) {
>  166       st->print(" %s", loader_klass != NULL ? 
> loader_klass->external_name() : "??");
>  167       st->print(" {" PTR_FORMAT "}", p2i(_loader_oop));
>  168     }
>
> Since you are in that file, it'd help to update line 162 to include 
> the address.  I will leave the question to the serviceability team on 
> showing loader oop address vs the identity hash depending how it's 
> intended to be used for troubleshooting. Maybe keep it as is and file 
> an issue to resolve for 11.
I have updated line 162 to reflect the current output and will open an 
RFE for the serviceability team to decide if showing the loader oop 
address is still needed given the identity hasn.
Thanks for the review!
Lois

>
> Mandy