GuaranteedSafepointInterval clarification

[Vitaly Davidovich]

But the VM thread does not actually initiate the safepoint unless the
inline cache indicates it has entries? So while this safepoint isn't
initiated synchronously by anything, it's initiated by deferred work?

sent from my phone
On May 29, 2015 10:42 PM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 30/05/2015 9:23 AM, Vitaly Davidovich wrote:
>
>>     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).
>>
>
> No it isn't a VM operation - there is no VMOperation being executed. The
> fact there is no VM op is what tells you this safepoint is due to some
> other means ie the periodic safepoint caused by GuarnteedSafepointInterval.
>
> David
>
>  Thanks
>>
>> On Fri, May 29, 2015 at 6:56 PM, David Holmes <david.holmes at oracle.com
>> <mailto: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>
>>         <mailto: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
>>
>>
>>