JDK-8043764 : JEP 228: Add More Diagnostic Commands
  • Type: JEP
  • Component: hotspot
  • Sub-Component: svc
  • Priority: P2
  • Status: Closed
  • Resolution: Delivered
  • Fix Versions: 9
  • Submitted: 2014-05-22
  • Updated: 2017-03-07
  • Resolved: 2016-10-20
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8054888 :  
JDK-8054889 :  
JDK-8054890 :  
JDK-8054891 :  
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.

Comments
print_vm_state command will be delivered as a standalone feature in JDK-8027429
21-09-2015

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.
22-10-2014

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
19-08-2014

Mikael, could you, please, take care of the "Endorsed By"?
28-07-2014

print_utf8pool: We need to check if this is really necessary and what use case it serves.
09-06-2014