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

[mandy chung]

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

Mandy