Strange safe-point banding behavior

David Holmes david.holmes at oracle.com
Thu Feb 19 10:38:13 UTC 2015


On 19/02/2015 7:11 PM, Kirk Pepperdine wrote:
> Hi David,
>
> Thanks, not sure how I missed this one. However, if GuaranteedSafepointInterval=1000ms, then how can we see application runtimes that are far greater than 1000ms?

You need to look at exactly what those timers actually measure - it's 
been a while since I have done so - I'm not sure what "application run 
time" actually is.

David

> Regards,
> Kirk
>
> On Feb 19, 2015, at 9:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>
>> Hi Kirk,
>>
>> GuaranteedSafepointInterval has a default value of 1000ms. It's a diagnostic flag so you can try changing it.
>>
>> The reason for this is to ensure certain housekeeping tasks that must occur at a safepoint happen with some regularity eg monitor scavenging.
>>
>> David
>>
>> On 19/02/2015 6:10 PM, Kirk Pepperdine wrote:
>>> Hi all,
>>>
>>> I can’t say that I’ve taken this as far as I could as of yet but I think I can start to ask questions.
>>>
>>> I’ve seen what I call a banding artifact in a number of GC logs. The latest prompted me to investigate further. In the latest case Application runtime is being reported very frequently a ~1 second. It is being reported some what less frequently every ~2 seconds. So that means a safe point is being called for very frequently at these times so in amongst all of the other application runtime data points these points from a solid line in the chart. Now there are intermixed runtimes that go longer than 2 seconds and of course they are shorter than 1 second.
>>>
>>> When we looked at PrintSafepointStatistics we get “no vm operation” which means sstats->_vmop_type == -1 which implies that the VM_Operation has not been set.
>>>
>>> Question is; why would a safepoint be called for with  no VM_Operation? Looking at the code I would say it’s quite common. I’ve turned on safepoint tracing for other applications and have seen other even more bizarre banding patterns which all appear to be due to some regular behavior.
>>>
>>> This happens on all recent (and most likely older) versions of the JVM.
>>>
>>> Kind regards,
>>> Kirk
>>>
>


More information about the hotspot-dev mailing list