JDK-8146551 : The output from -Xlog:classresolve=info looks not useful
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-01-06
  • Updated: 2016-06-08
  • Resolved: 2016-03-11
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 b115Fixed
Related Reports
Relates :  
JDK-8158565 - Consider to clean up classresolve "info" level msgs
Relates :  
JDK-8144874 - Reimplement TraceClassResolution with Unified Logging
Description
It would be good to have more meaningful logging for class resolution. From cplummer email.

The log mostly has [classresolve] entries. Often there are many, sometimes a hundred or more, for the same file, even for the same line number in the file:

 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 [0.179s][info   ][classresolve] java.lang.Integer$IntegerCache java.lang.Integer Integer.java:1049
 
This logging was converted to 'info' level but this is not terribly informative.

I made this a 'bug' because this output overwhelms meaningful output in log=all (and chris is seeing GCBasher log files as big as 2.5g).   This output is excessive.
Comments
For "trace class loading", for example, I expect the info level to produce at least one record per class loaded. Similarly for class resolution. When I ask for that I expect a non-trivial volume of logging information. If you turn on "info" for every single kind of logging that exists in the VM then the combined result will indeed be "insane" for some definition thereof. Tuning on all info based logging seems a pointless option to me - you are probably only really interested in a specific subset of tags. I view "info" "debug" "trace" as synonyms for "coarse" "finer" "finest" and so applicable to all tags. If you instead view "info" "debug" "trace" as synonyms for some priority/importance based classification then you may not expect some tags to utilize "info" for example because you don't think it is important enough.
04-03-2016
To me it sounds very strange that any logging on the info level should result in an insane amount of output. That just seems like the wrong use of "info". So, to me -Xlog:all should definitely be considered a useful option.
03-03-2016
I agree with Coleen. The ability to do -Xlog:all may seem convenient but I don't think it is a practical option to use. All of the "info" level logging could well be an "insane" amount - and I see no problem with that.
27-01-2016
No, -Xlog:all is never going to give you a sane amount of input. That's why we picked debug for many tags, but that's controversial because if you want <sometag> logging for runtime, you have to remember which level it's on. It's only going to get worse.
27-01-2016
This also affects the "exceptions" tag, should I file a separate issue for that? My idea is that "-Xlog:all" should give a sane amount of output.
27-01-2016
I've updated the gcbasher configuration to use -Xlog:gc* rather than -Xlog:all, which should help with the log size problem. That doesn't address any issues of classresolve logging being uninformative.
07-01-2016