JDK-8151342 : Add module name/version to class histogram output
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9-repo-jigsaw
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-03-05
  • Updated: 2016-05-26
  • Resolved: 2016-04-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b120Fixed
Related Reports
Blocks :  
Relates :  
Description
We should update the class histogram to include module information when the class is in a named module. This will really benefit `jmap -histo <pid>` and `jcmd <pid> GC.class_histogram`.

Stack traces and thread dumps already include the module name and version where possible and we should use the same format.
Comments
This fix will use new instance methods added by JDK-8152844
15-04-2016

I would think <module>/<classname> or <classname> (<module>) would be clearer.
13-04-2016

Does this output look okay? (JBS messed up the column alignment.) Also, I'd prefer not to make displaying the module information be optional. num #instances #bytes class name module ----------------------------------------------------- 1: 7879 1575328 [B java.base@9-internal 2: 1801 216720 java.lang.Class java.base@9-internal 3: 5739 183648 java.util.HashMap$Node java.base@9-internal 4: 7068 169632 java.lang.String java.base@9-internal 5: 1894 95544 [Ljava.lang.Object; java.base@9-internal 6: 786 90792 [I java.base@9-internal 7: 936 85048 [Ljava.util.HashMap$Node; java.base@9-internal 8: 907 79816 java.lang.reflect.Method java.base@9-internal 9: 2297 73504 java.util.concurrent.ConcurrentHashMap$Node java.base@9-internal 10: 991 47568 java.util.HashMap java.base@9-internal 11: 21 36216 [C java.base@9-internal 12: 320 23040 java.lang.reflect.Field java.base@9-internal 13: 889 19744 [Ljava.lang.Class; java.base@9-internal 14: 46 19104 [Ljava.util.concurrent.ConcurrentHashMap$Node; java.base@9-internal 15: 475 19000 java.lang.ref.Finalizer java.base@9-internal 16: 1024 16384 ClassHistogramTest$TestClass
13-04-2016

We're using <module>[@<version>]/<source-file> in the stack traces and the launcher supports `java -m <module>/<mainclass>`. It would be nice to be consistent if we can. One comment on the examples is that the version string is "9-internal" rather than "9".
18-03-2016

Hi Markus, That sounds like a good solution. Thanks, Harold
17-03-2016

Hi Harold, spontanously I would like to reduce the focus of the module here if possible. By having the module@version/ before the actual type you are trying to inspect, I think it is getting harder to read these lines (and what they correspond to). Is there maybe a way to keep existing output: 1: 214818 31706808 [B (java.base@9-internal) 2: 213614 5126736 java.lang.String (java.base@9-internal) 3: 110059 2641416 com.sun.javatest.finder.BinaryTestFinder$TestTree$Node 4: 62702 1716392 [I (java.base@9-internal) Optionally just print the module information if a "verbose" switch is passed. It is not the primary information you are interested in. What do you think? Thanks
17-03-2016

Proposed sample output. Num 3 is in an unnamed module so no module@version info. (The alignment of the fields looked okay until I pasted it into JBS.) num #instances #bytes module@version/class name ------------------------------------------------------------- 1: 214818 31706808 java.base@9-internal/[B 2: 213614 5126736 java.base@9-internal/java.lang.String 3: 110059 2641416 com.sun.javatest.finder.BinaryTestFinder$TestTree$Node 4: 62702 1716392 java.base@9-internal/[I ... 1292: 1 16 jdk.localedata@9-internal/sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo Total 799560 49360920
17-03-2016