Today the TraceClassLoading logging option is used to print out information related to class loading:

A typical log contains lines of the form:

[Loaded <classname> from <code_source>]

For example: with jdk9 as of 2015/05/05

$ java -cp /tmp -XX:+TraceClassLoading Foo
[Loaded java.lang.Object from java/lang/Object.class]
[Loaded java.io.Serializable from java/io/Serializable.class]
...
[Loaded Foo from file:/tmp/]

However, there are a few issues with the current implementation
[1] The logs are intermixed with the program's standard output,
    so it's hard to extract and process.
[2] Some logs are not atomic, so it could be corrupted by the output
    of other Java threads
[3] No information related to the class hierarchy and class loader

Planned optimizations of CDS require a more detailed and reliable logging
mechanism so that we can capture all the necessary information related
to class loading. This would make it possible to

[1] Store all classes loaded by a process into a CDS archive
[2] Analyze class loading performance using off-line tools.


=========== proposed fix ======================
The proposal is to implement the "classload" and "classloaderdata" tags for Unified Logging (JDK-8059747), and print out detailed information about the class hierarchy, code source location, and classfile data.

(a) -Xlog:classloaderdata=<level>

This logging tag replaces the old TraceClassLoaderData flag.

Also, when a ClassLoaderData is created, the log is augmented to print out the toString() value of the loader. This allows the user of the log to identify the class loader instance.

(b) -Xlog:classload=<level>

Note that as of this RFE, we are not changing the existing TraceClassLoading flag. Many external tools depend on this flag. If we want to replace TraceClassLoading with -Xlog:classload=<level>, that needs to be done in a different RFE.

    -Xlog:classload=<level>

Two levels are supported: debug and trace.

In "debug" level, the output is the same as with the old TraceClassLoading flag.

In "trace" level, each line in the log will correspond to a newly loaded class, of the following format

CLASSNAME klass: PTR super: PTR <interfaces: INTF_LIST> source: CODE_SOURCE by CLASS_LOADER bytes: CFSIZE checksum: CFCRC

    CLASSNAME is the dot-separated fully qualified class name

    PTR is in the form of a hex number: 0x[0-9a-f]+

    INTF_LIST is one or more PTRs, separated by a single space character

    CODE_SOURCE is the same output as before

    CLASS_LOADER has the one of the 2 forms:
        [NULL class_loader]
        [class loader PTR 'CLASS_LOADER_TYPE']

    CFNUM is a decimal integer

    CFCRC is in the form of a hex number: 0x[0-9a-f]+

Meaning of the log:

klass: PTR
PTR is the unique identifier for this class.

super: PTR
PTR is the unique identifier for the super class of the current class.

interfaces: INTF_LIST
This portion is optional. It's printed only if the current class has directly
implemented any interfaces. INTF_LIST is one of more unique identifiers
for the interfaces directly implemented by the current class.

CLASS_LOADER:
The PTR is the unique identifier for the instance of the defining class loader of the current class.

CFSIZE
The length of the classfile data (in number of bytes) that defined this class.

CFCRC
The 32-bit CFC of classfile data that defined this class.

===================================
See attachment for a sample log file:

java -cp ~/tmp -Xlog:classloaderdata=debug,classload=trace Foo > ~/sample_log.txt