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

JEP 228: Add More Diagnostic Commands

    Details

    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
      svc
    • Scope:
      Implementation
    • Discussion:
      serviceability dash dev at openjdk dot java dot net
    • Effort:
      S
    • Duration:
      M
    • Alert Status:
       Green
    • JEP Number:
      228

      Description

      Summary

      Define additional diagnostic commands, in order to improve the diagnosability of Hotspot and the JDK.

      Description

      This is a list of the new commands (exact names are TBD):

      print_class_summary

      • Print a list of all loaded classes and their inheritence structure.
      • Responsible group: runtime

      print_codegenlist

      • Print methods queued for compilation with either C1 or C2 (separate queues)
      • Responsible group: compiler

      print_utf8pool

      • Print all UTF-8 string constants.
      • Responsible group: runtime

      datadump_request

      • Signal the JVM to do a data-dump request for JVMTI.
      • Responsible group: serviceability

      dump_codelist

      • Print n-methods (compiled) with full signature, address range, and state (alive, nonentrant, and zombie).
      • Allow selection of printing to stdout or to a file.
      • Allow XML or text printout.
      • Responsible group: compiler

      print_codeblocks

      • Print the size of the code cache and a list of blocks in the code cache, with adresses.
      • Responsible group: compiler

      set_vmflag

      • Set a command-line flag/option in VM or the libraries.
      • Responsible group: servicability

      Testing

      There needs to be a test for each command to verify the output.

        Issue Links

          Activity

          Hide
          sla Staffan Larsen (Inactive) added a comment -
          print_utf8pool: We need to check if this is really necessary and what use case it serves.
          Show
          sla Staffan Larsen (Inactive) added a comment - print_utf8pool: We need to check if this is really necessary and what use case it serves.
          Hide
          jbachorik Jaroslav Bachorík added a comment -
          Mikael, could you, please, take care of the "Endorsed By"?
          Show
          jbachorik Jaroslav Bachorík added a comment - Mikael, could you, please, take care of the "Endorsed By"?
          Hide
          sla Staffan Larsen (Inactive) added a comment -
          From: Paul Nauman <paul.nauman@oracle.com>
          Subject: Re: Do we need a diagnostic command to print all utf8 strings
          Date: 18 augusti 2014 16:39:16 CEST

          I once fixed a bug where class name strings were not being released when corresponding classes were unloaded. The customer used the print_utf8pool command to demonstrate the bug and test the fix.

          - Paul
          Show
          sla Staffan Larsen (Inactive) added a comment - From: Paul Nauman < paul.nauman@oracle.com > Subject: Re: Do we need a diagnostic command to print all utf8 strings Date: 18 augusti 2014 16:39:16 CEST I once fixed a bug where class name strings were not being released when corresponding classes were unloaded. The customer used the print_utf8pool command to demonstrate the bug and test the fix. - Paul
          Hide
          sla Staffan Larsen (Inactive) added a comment -
          utf8pool in JRockit prints what hotspot calls "symbols".

          In general diagnostic commands should not prohibit innovation in the JVM, they should be adapted to fit what the implementation looks like. Sometimes it may be worthwhile to store extra data to support diagnostic commands, but if an existing or proposed diagnostic command hinders development, then that command should be re-evaluated. There is no guarantee that the set of diagnostic commands will be the same from one release to the next, nor that the output will remain the same. Diagnostic commands are there to support the implementation and our debugging/troubleshooting of the JVM - not the other way around.

          In this case it makes sense to figure out what data is valuable to print for the symbols. Perhaps it is of little value to print the actual strings, but instead some statistics pertaining to the symbols. The name should also be re-considered. Perhaps "VM.symbols"?

          It is up to the implementor to design a valuable diagnostic command and run the design it by PM.
          Show
          sla Staffan Larsen (Inactive) added a comment - utf8pool in JRockit prints what hotspot calls "symbols". In general diagnostic commands should not prohibit innovation in the JVM, they should be adapted to fit what the implementation looks like. Sometimes it may be worthwhile to store extra data to support diagnostic commands, but if an existing or proposed diagnostic command hinders development, then that command should be re-evaluated. There is no guarantee that the set of diagnostic commands will be the same from one release to the next, nor that the output will remain the same. Diagnostic commands are there to support the implementation and our debugging/troubleshooting of the JVM - not the other way around. In this case it makes sense to figure out what data is valuable to print for the symbols. Perhaps it is of little value to print the actual strings, but instead some statistics pertaining to the symbols. The name should also be re-considered. Perhaps "VM.symbols"? It is up to the implementor to design a valuable diagnostic command and run the design it by PM.
          Hide
          jbachorik Jaroslav Bachorík added a comment -
          print_vm_state command will be delivered as a standalone feature in JDK-8027429
          Show
          jbachorik Jaroslav Bachorík added a comment - print_vm_state command will be delivered as a standalone feature in JDK-8027429

            People

            • Assignee:
              sla Staffan Larsen (Inactive)
              Reporter:
              sla Staffan Larsen (Inactive)
              Owner:
              Staffan Larsen (Inactive)
              Reviewed By:
              Mikael Vidstedt
              Endorsed By:
              Mikael Vidstedt
            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:
                Integration Due: