RFR (M) 8198720: Obsolete PrintSafepointStatistics, PrintSafepointStatisticsTimeout and PrintSafepointStatisticsCount options

[coleen.phillimore at oracle.com]

On 7/11/18 12:22 PM, Lois Foltan wrote:
> On 7/11/2018 9:15 AM, coleen.phillimore at oracle.com wrote:
>>
>> I've kept the output the same and converted to UL.  To get the lines 
>> not to shift due to uptime printing, you can use the option:
>>
>> -Xlog:safepoint+stats=debug:<outputfile>:tags or none instead of tags.
>>
>> I could alias PrintSafepointStatistics to this: 
>> -Xlog:safepoint+stats=debug::none as this option gets verbose. Having 
>> the ability to send the output to a gc.log file is pretty nice though 
>> so worth using all the logging options.
>>
>> Please review:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8198720.02/webrev
>
> Hi Coleen,
> This looks good.  One minor comment:
>
> share/runtime/safepoint.hpp line #111 - can you clarify why the "#if 
> 0/#endif code shouldn't just be removed?

Hi Lois, Thanks for the review and thank you for noticing this. Yes, 
this code should be removed, which I will do before checking it in.

thanks!
Coleen
>
> Thanks,
> Lois
>
>>
>> Tested with tier1-3.
>>
>> Thanks,
>> Coleen
>>
>> On 7/9/18 11:26 PM, coleen.phillimore at oracle.com wrote:
>>>
>>> Hi Aleksey,
>>>
>>> I rewrote the logging to use UL and to keep the old format: see 
>>> http://cr.openjdk.java.net/~coleenp/gc.log
>>> It does shift when the time in the logging adds another digit. I 
>>> don't know how to fix that.   Does this look ok otherwise?
>>>
>>> thanks,
>>> Coleen
>>>
>>>
>>> On 7/9/18 5:42 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>>
>>>> On 7/9/18 4:08 PM, Aleksey Shipilev wrote:
>>>>> Thank you!
>>>>>
>>>>> Most latency-savvy folks "out there" run with some sort of 
>>>>> safepointing profiling, which in many
>>>>> cases include PrintSafepointStatistics tables.
>>>>
>>>> That was the original reason I was looking at this logging. I think 
>>>> the trouble with the times is that they are ms and mostly zero.  I 
>>>> wonder if MILLIUNITS would be better for these times:
>>>>
>>>>              (int64_t)(sstats->_time_to_spin / MICROUNITS),
>>>>              (int64_t)(sstats->_time_to_wait_to_block / MICROUNITS),
>>>>              (int64_t)(sstats->_time_to_sync / MICROUNITS),
>>>>              (int64_t)(sstats->_time_to_do_cleanups / MICROUNITS),
>>>>              (int64_t)(sstats->_time_to_exec_vmop / MICROUNITS));   
>>>> <= this has nonzero values for GC pauses
>>>>
>>>> What do you think?
>>>>
>>>> thanks,
>>>> Coleen
>>>>>
>>>>> -Aleksey
>>>>>
>>>>> On 07/09/2018 08:35 PM, coleen.phillimore at oracle.com wrote:
>>>>>> Okay, somehow the columns of numbers didn't look very useful on 
>>>>>> my screen to me, and I wanted to
>>>>>> convert this to UL (and straighten out the logic), so that's why 
>>>>>> I made this change.   I asked
>>>>>> around internally to see which people would care about the format 
>>>>>> change and didn't find anyone
>>>>>> specific.  Now I know!
>>>>>>
>>>>>> Let me rework this to use UL but keep the table.
>>>>>>
>>>>>> I'll withdraw this change for now.
>>>>>>
>>>>>> Thank you for the quick feedback.
>>>>>> Coleen
>>>>>>
>>>>>> On 7/9/18 1:58 PM, Aleksey Shipilev wrote:
>>>>>>> On 07/09/2018 07:48 PM, coleen.phillimore at oracle.com wrote:
>>>>>>>> Summary: Convert PrintSafepointStatistics to UL
>>>>>>>>
>>>>>>>> open webrev at 
>>>>>>>> http://cr.openjdk.java.net/~coleenp/8198720.01/webrev
>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8198720
>>>>>>> The synopsis is misleading: it is not only obsoleting 
>>>>>>> PrintSafepoint* options, it also reformats the
>>>>>>> output!
>>>>>>>
>>>>>>> We did JDK-8180482 not that long ago, and the reason was that 
>>>>>>> both people and machine tools are
>>>>>>> accustomed to the particular non-noisy format for that table. I 
>>>>>>> am not at all convinced that
>>>>>>> proposed format [2] is better than current version [3]. Can we 
>>>>>>> keep (at least some resemblance of)
>>>>>>> the old format, please?
>>>>>>>
>>>>>>> -Aleksey
>>>>>>>
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180482
>>>>>>> [2] 
>>>>>>> https://bugs.openjdk.java.net/secure/attachment/75330/out.safepoint-logging
>>>>>>> [3] http://cr.openjdk.java.net/~shade/8180482/after.txt
>>>>>>>
>>>>>
>>>>
>>>
>>
>