RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.

[David Holmes]

On 27/01/2016 6:25 AM, Max Ockner wrote:
> I am working on changing the affected tests to look for the proper output.

Late to the party but should we not be trying to maintain the existing 
basic format of the log messages so that anyone who already regularly 
uses -verbose:class and has scripts etc that check this, will still see 
basic things like:

[Loaded xxx from yyyy]

?

David

  -Max
>
> On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>>
>> Thanks for recapping the decision.  I didn't remember it from all our
>> discussions, etc.
>>
>> As the one who looks at these logs and is parsing these for CDS, thank
>> you for confirming that this is intentional.  Do you really have two
>> different output files for info and debug info?
>>
>> Max/Ioi can you add a comment to the code.  This looks easily like
>> someone would "fix" because it looks funny.
>>
>> Thanks,
>> Coleen
>>
>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>
>>>> Hi Max,
>>>>
>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>
>>>>
>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>
>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>> }  else
>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>> }
>>>>
>>>
>>> Hi Coleen,
>>>
>>> The case for the 'else' has been discussed before. Please refer to
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>
>>>
>>> To recap: the reason for NOT having the 'else' is for:
>>>
>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>> -Xlog:classload=debug:file=debug.log Foo
>>>
>>> If you add the 'else' there,  the debug-level output intended for
>>> debug.log will be missing.
>>>
>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>> But if you do that, the info.log file will have no content.
>>>
>>> The 'info' level looks like this
>>>
>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>
>>> The 'debug' level looks like this (in a single line):
>>>
>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>
>>> Because UL buffers at the line level, I cannot split the output into
>>> two parts like this:
>>>
>>>   [info ][classload] java.lang.Object source: ...
>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>
>>> Otherwise some unrelated output may be interleaved between the two
>>> lines, making the output impossible to parse. The ability to parse
>>> the output is very important to tools that analyze the class loading
>>> behavior (e.g., tools related to CDS).
>>>
>>> Due to this limitation of UL, I think our only choice is to repeat
>>> the class name and 'source' in both info and debug levels, hence NO
>>> 'else' in the code you quoted:
>>>
>>>   [info ][classload] java.lang.Object source: ..
>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>
>>> Thanks
>>> - Ioi
>>>
>>>
>>>
>>
>