InlineCacheBuffer + GuaranteedSafepointInterval
vitalyd at gmail.com
Fri Jun 5 15:48:03 UTC 2015
Thanks for the insight. Do you know offhand the condition(s) that prevent
updating IC call sites atomically?
Also, I'm assuming this triggers when a new receiver is seen at a callsite
that's already using an IC, is that right? So something like lower
CompileThreshold may exacerbate this a bit if the shorter profile does not
record sufficient # of receiver types.
On Fri, Jun 5, 2015 at 11:36 AM, Roland Westrelin <
roland.westrelin at oracle.com> wrote:
> > What exactly triggers IC holders to be eligible for deletion?
> As I remember, IC stubs are stubs that are sometimes used when an IC call
> sites change state and updating the call site can’t be done atomically. So
> we insert an IC stub between the call site and the target method and
> there’s an extra jump on that path. At a safepoint, we can remove all the
> IC stubs by updating the call sites that couldn’t be updated atomically
> because there’s no concurrency issue anymore.
> > The reason behind this question is I'd like to eliminate "unnecessary"
> safepoints that I'm seeing, but would like to understand implications of
> this with respect to compiler infrastructure (C2, specifically). I have a
> fairly large code cache reserved, and the # of compiled methods isn't too
> big, so space there shouldn't be an issue.
> > Why is GuaranteedSafepointInterval based safepoint actually gated on
> this particular check? If I turn off background safepoints (i.e.
> GuaranteedSafepointInterval=0) or set them very far apart, am I risking
> stability problems, at least in terms of compiler?
> As far as I can tell and as far as IC stubs are concerned you risk a
> performance loss (if you have a very hot call site with the extra jump
> caused by the IC stub) and running out of IC stubs which, it seems from the
> code, would trigger a safepoint.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev