RFR(S): 8160064: StackWalker implementation added logging option without using UL

[Coleen Phillimore]

On 9/28/16 10:47 AM, Rachel Protacio wrote:
> Hi,
>
>
> On 9/27/2016 6:54 PM, David Holmes wrote:
>> Hi Rachel,
>>
>> On 28/09/2016 5:47 AM, Rachel Protacio wrote:
>>> Hi,
>>>
>>> Please review this small fix correcting the StackWalker print output
>>> mechanism by moving it to Unified Logging. Includes a new jtreg test,
>>> and passes JPRT.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160064
>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8160064/
>>
>> Was there a specific reason to make this available in product rather 
>> than just "develop" as the existing flag was?
> No, that was entirely my mistake. I didn't notice it was a develop 
> flag. Will update that.

I thought I'd read this comment but then missed it.  Since this logging 
1. doesn't impact performance, 2. doesn't add to the JVM code size, and 
3. (I forgot what 3 was), the bias is to make logging a product level flag.

Particularly as the core-libs team, who will use this logging generally 
only builds product jvms.

>>
>>       if (!ShowHiddenFrames && (skip_hidden_frames(mode) || 
>> get_caller_class(mode))) {
>>         if (method->is_hidden()) {
>> !         {
>> !           ResourceMark rm;
>> !           outputStream* st = Log(stackwalk)::trace_stream();
>>
>> This should check if logging is enabled before potentially wasting 
>> time on the ResourceMark etc. Ditto for other places. Did you revert 
>> this due to Coleen's query? We want to minimise what happens when 
>> logging is not enabled - ideally it would be 100% free.
> Thanks for pointing that out. Will put in checks.
>>
>> I also query why all the logging entries are at the trace level?

Since Daniel said that the logging would be used for debugging, then 
maybe it belongs at the debug level.

Again, our bias with UL is to not put things on the info level because 
even if no one in their right mind would turn on all info logging, this 
doesn't belong in the output that they should get with that.

Thanks,
Coleen

> Will address at tip of thread...
> Rachel
>>
>> Thanks,
>> David
>>
>>> Thank you!
>>> Rachel
>