RFR: 8143157: Convert TraceVMOperation to Unified Logging

kirk.pepperdine at gmail.com kirk.pepperdine at gmail.com
Fri Nov 20 04:53:11 UTC 2015


>> 
>> How about?
>> 
>>     [0.257s][debug  ][vmoperation] VM_Operation begin
>> (0x00007f74e589c700):
>>     G1CollectFull, mode: safepoint, requested by thread
>> 0x00007f74dc018000
>>     <code from doit() and not from TraceVMOperation>
>>     [0.272s][debug  ][vmoperation] VM_Operation end (0x00007f74e589c700):
>>     G1CollectFull, mode: safepoint, requested by thread
>> 0x00007f74dc018000
> 
> That looks fine - thanks.

I would suggest that a time stamp be added to the body of the log statement. The UL provided time stamp is when UL logs and in a test environment these are likely to be close enough not to matter. However, in a production environment there could be slippage between occurrence and when decoration occurs.

>> 
>> This is getting really long and I'm not seeing how to respond. Should we
>> not convert the runtime tracing and and printing functions to Unifield
>> Logging?  Should the framework be redone so that it satisfies all of
>> your theoretical constraints?   Max wrote up a proposal how to convert
>> the runtime flags to UL.  It's getting really tiresome to defend the
>> framework with every flag that we try to convert.  I'm not sure what you
>> would prefer we do.

I’m very sorry that you feel the need to defend UL, it was no the intent of the discussion. Aside from a few rough edges, the implementation seems very reasonable. It’s the design that is at issue. I don’t want to start the discussion again because the ship has obviously sailed on but my concerns with this framework (aside from the tag/level issues) have been based on my experiences tuning applications and seeing what the real problems are. Why logging generally doesn’t show up as a problem is an issue with visibility. People generally don’t recognize the problem when they see it. Just yesterday I ran into yet another example of this. Unfortunately, these problems tend not to show up in test/lab environments. Baking it into the JVM makes it even less visible to people in production environments. All I’ve done is pointed out implementations that I’ve found to be less problematic written by those that are happy to contribute those ideas to this effort. All said, I very much want to be wrong on every point I’ve raised.

Regards,
Kirk



More information about the hotspot-runtime-dev mailing list