GuaranteedSafepointInterval clarification

[David Holmes]

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
>