Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8079408

Improve class loading log (with unified logging)



    • Subcomponent:
    • Resolved In Build:


      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.


      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.

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

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

      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


          Issue Links



              mockner Max Ockner (Inactive)
              iklam Ioi Lam
              0 Vote for this issue
              7 Start watching this issue