GuaranteedSafepointInterval clarification

[Vitaly Davidovich]

>
> You can change the interval you just need to add the
> UnlockDiagnosticVMOptions flag to do so.


Yeah I know, but there's more scrutiny when diagnostic vm options are
unlocked on production machines :).  It could also mean someone else could
(accidentally, perhaps, not realizing it's diagnostic) enable another
diagnostic command.

Also, I suggest someone add a name to this vm op in the output, as
mentioned in my original email, as seeing "no vm operation" in the log is
(a) confusing to someone viewing this for the first time and (b) somewhat
of a lie since this *is* a vm operation :) (whether "InlineCacheBuffer
maintenance" or "GuaranteedSafepointInterval" or some other name is best is
up to you guys).

Thanks

On Fri, May 29, 2015 at 6:56 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 29/05/2015 11:52 PM, Vitaly Davidovich wrote:
>
>> Hi David,
>>
>> Thanks for the response.  What resource shortage are you referring to
>> wrt GSI? I'd actually like to increase the interval as having the VM
>> thread wake up every 1s and get CPU time (imagine a case where the JVM
>> has been affinitized to a subset of CPUs on the machine) is undesirable
>> as it may interfere with critical app threads.  Hence seemed like a
>> legit tunable given the very low default.
>>
>
> It is mainly the code-cache sweeping, but then as a side-effect you get
> the monitor cleanup and some other things I can't recall of the top of my
> head.
>
> You can change the interval you just need to add the
> UnlockDiagnosticVMOptions flag to do so.
>
> David
> -----
>
>  sent from my phone
>>
>> On May 28, 2015 9:25 PM, "David Holmes" <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Vitaly,
>>
>>     I'll try to answer your questions but these are just my
>>     views/understanding of things.
>>
>>     On 29/05/2015 6:45 AM, Vitaly Davidovich wrote:
>>
>>         Hi all,
>>
>>         Could someone explain the reasoning for 1s being the default
>>         value here? It
>>         seems quite low given the types of things it appears to handle
>>         (monitor
>>         deflation, inline cache updates, symbol table rehashing, nmethod
>>         sweeping,
>>         etc).
>>
>>
>>     A balance between not inducing STW safepoints too frequently, while
>>     still ensuring timely cleanup of specific resources in cases where
>>     it is not happening by virtue of other safepoint related VM
>>     operations occurring.
>>
>>         Also, I do not always see these safepoints initiated every ~1s.
>>         Looking at
>>         SafepointSynchronize::is_cleanup_needed(), this seems to kick in
>>         only when
>>         InlineCacheBuffer has some entries.  Is that right? This code
>>         will only run
>>         if compiler has updated inline caches?
>>
>>
>>     Although there are a number of cleanup actions that will occur at a
>>     safepoint, only the InlineCacheBuffer::is_empty() related cleanup is
>>     deemed necessary to run at least once a second. The other cleanup
>>     actions are assumed to be less critical, and normally handled by the
>>     "natural" occurrence of safepoint VM operations in the execution of
>>     an application.
>>
>>         Why is GuaranteedSafepointInterval a diagnostic option and not
>>         full product
>>         like, say, a GC tuning option?
>>
>>
>>     GC tuning knobs are expected to turned by end users in the normal
>>     course of business. Tweaking the GSI is not something that many
>>     people ever have to adjust, and it would generally be done as part
>>     of diagnosing a resource shortage of some kind.
>>
>>     Cheers,
>>     David
>>
>>         Finally, when tracing safepoint stats, these cleanup ones appear
>>         as "no vm
>>         operation" in the output -- it seems like it would be nicer to
>> print
>>         something like "GuaranteedSafepointInterval" or something to
>>         that effect.
>>
>>         Thanks
>>
>>