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

[coleen.phillimore at oracle.com]

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
>>>
>