[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-runtime-dev
Subject: Re: GuaranteedSafepointInterval clarification
From: David Holmes <david.holmes () oracle ! com>
Date: 2015-05-30 6:19:52
Message-ID: 55695688.6090006 () oracle ! com
[Download RAW message or body]
On 30/05/2015 2:43 PM, Vitaly Davidovich wrote:
> 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?
Part of the safepoint protocol is to do various cleanups that have to be
done at safepoints. These are all deferred cleanups if you like. Only
cache status is deemed important enough to force a periodic safepoint.
So when the safepoint stats list the VM operations it's appropriate to
indicate that there was no VM operation in this case. Yes you need to
know more about the safepoint code to understand exactly what happens -
but that's true of all the states - you don't know what the time
intervals truly represent without examining the code.
David
> sent from my phone
>
> On May 29, 2015 10:42 PM, "David Holmes" <david.holmes@oracle.com
> <mailto:david.holmes@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@oracle.com <mailto:david.holmes@oracle.com>
> <mailto:david.holmes@oracle.com
> <mailto:david.holmes@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@oracle.com <mailto:david.holmes@oracle.com>
> <mailto:david.holmes@oracle.com
> <mailto:david.holmes@oracle.com>>
> <mailto:david.holmes@oracle.com
> <mailto:david.holmes@oracle.com>
> <mailto:david.holmes@oracle.com
> <mailto:david.holmes@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
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic