RFR(XS): 8202415: Incorrect time logged for monitor deflation
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Nov 27 21:47:14 UTC 2018
On 11/27/18 4:42 PM, David Holmes wrote:
> Hi Dan,
>
> Updated webrev looks good - thanks.
Thanks for catching the bug!!
> Only nit - for seperate RFE - is that it doesn't make much sense
> reporting these times in seconds when all the action is down at the
> nano-/micro- second level.
Agreed that this should be re-examined at some point. The new logging
for deflating per-thread idle monitors is matching the existing logging
for deflating global idle monitors. I suspect it was done that way
because of limitations of elapsedTimer...
Thanks for the re-review.
Dan
>
> Thanks,
> David
>
> On 28/11/2018 2:51 am, Daniel D. Daugherty wrote:
>> Running the logging option on a simple Hello.java:
>>
>> $ jr -Xlog:safepoint+cleanup=info Hello | grep deflating
>> [0.112s][info][safepoint,cleanup] deflating global idle monitors,
>> 0.0000002 secs
>> [0.112s][info][safepoint,cleanup] deflating per-thread idle monitors,
>> 0.0000028 secs
>> [0.119s][info][safepoint,cleanup] deflating global idle monitors,
>> 0.0000002 secs
>> [0.119s][info][safepoint,cleanup] deflating per-thread idle monitors,
>> 0.0000016 secs
>> [0.128s][info][safepoint,cleanup] deflating global idle monitors,
>> 0.0000001 secs
>> [0.128s][info][safepoint,cleanup] deflating per-thread idle monitors,
>> 0.0000016 secs
>>
>> Dan
>>
>> On 11/27/18 10:28 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I re-reviewed my webrev and verified that the only line that I messed
>>> up is the one that David spotted. Thanks for the catch!
>>>
>>> Full webrev against jdk/jdk:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8202415-webrev/1_for_jdk_jdk.full/
>>>
>>> Incremental webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8202415-webrev/1_for_jdk_jdk.inc/
>>>
>>> Sanity check build and retest is in process.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>> On 11/27/18 9:16 AM, Daniel D. Daugherty wrote:
>>>> Hi David,
>>>>
>>>> Thanks for the review!More below.
>>>>
>>>> On 11/26/18 11:04 PM, David Holmes wrote:
>>>>> Hi Dan,
>>>>>
>>>>> On 27/11/2018 5:36 am, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> I have an extra small fix for the following bug:
>>>>>>
>>>>>> JDK-8202415 Incorrect time logged for monitor deflation
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202415
>>>>>>
>>>>>> Here's the webrev URL:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8202415-webrev/0_for_jdk_jdk/
>>>>>
>>>>> Why is it that you only track the time for
>>>>>
>>>>> log_is_enabled(Debug, monitorinflation)
>>>>
>>>> Ouch. That's a cut-n-paste error from when I manually extracted
>>>> the patch out of my monitor deflation repo into the current
>>>> jdk/jdk baseline repo.
>>>>
>>>> This line:
>>>>
>>>> L1695: if (log_is_enabled(Debug, monitorinflation)) {
>>>>
>>>> should be:
>>>>
>>>> L1695: if (log_is_enabled(Info, safepoint, cleanup)) {
>>>>
>>>> I must have grabbed from the wrong diff when I did that part.
>>>>
>>>>
>>>>> but you only report the time under:
>>>>>
>>>>> log_info(safepoint, cleanup)
>>>>>
>>>>> ?? Unless you explicitly know to enable monitorinflation enabling
>>>>> the safepoint-cleanup logging will just report zero. I would have
>>>>> expected to see the deflation time recorded and printed for both
>>>>> log settings
>>>>
>>>> The intent for the new "deflating per-thread idle monitors" log mesg
>>>> is to match the existing "deflating global idle monitors" log mesg.
>>>> Both should be controlled by: log_is_enabled(Info, safepoint, cleanup)
>>>>
>>>>
>>>>>
>>>>> And under what conditions is the existing "global deflation" time
>>>>> reported?
>>>>
>>>> That's done by this piece of code:
>>>>
>>>> src/hotspot/share/runtime/safepoint.cpp:
>>>> L621: TraceTime timer(name, TRACETIME_LOG(Info,
>>>> safepoint, cleanup));
>>>>
>>>> That helper object includes a call to:
>>>>
>>>> log_is_enabled(Info, safepoint, cleanup)
>>>>
>>>> along with built-in timer support.
>>>>
>>>>
>>>>>
>>>>>> The fix has been tested with a Mach5
>>>>>> builds-tier1,hs-tier1,jdk-tier1,
>>>>>> hs-tier2,hs-tier3 job. The modified SafepointCleanupTest.java has
>>>>>> been verified to pass in all Mach5 configs.
>>>>>
>>>>> But the test doesn't enable monitorinflation logging so doesn't
>>>>> actually verify the logging works.
>>>>
>>>> It does when the right check is in place. :-(
>>>>
>>>>
>>>>>
>>>>>> This bug is currently targeted at jdk13, but I think it is safe
>>>>>> enough to be pushed to jdk12 if the reviewers agree.
>>>>>
>>>>> No problem with fixing in 12.
>>>>
>>>> Thanks.
>>>>
>>>> Dan
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Dan
>>>>
>>>>
>>>
>>>
>>
More information about the hotspot-runtime-dev
mailing list