<div dir="ltr">Hi Roland,<div><br></div><div>Thanks for the insight.  Do you know offhand the condition(s) that prevent updating IC call sites atomically?</div><div><br></div><div>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.</div><div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 5, 2015 at 11:36 AM, Roland Westrelin <span dir="ltr"><<a href="mailto:roland.westrelin@oracle.com" target="_blank">roland.westrelin@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> What exactly triggers IC holders to be eligible for deletion?<br>
<br>
</span>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.<br>
<span class=""><br>
> 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.<br>
><br>
> 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?<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Roland.</font></span></blockquote></div><br></div>