InlineCacheBuffer + GuaranteedSafepointInterval

[Vitaly Davidovich]

Understood, thanks John.

Am I right in my other question regarding when IC needs patching in first
place? If I see safepoint due to this, some IC saw a new receiver? Is there
a flag (non-debug) to see which call site and what new receiver appeared? I
may reorganize code to avoid this if possible.

sent from my phone
On Jun 5, 2015 1:08 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Jun 5, 2015, at 8:48 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> Thanks for the insight.  Do you know offhand the condition(s) that prevent
> updating IC call sites atomically?
>
>
> If you look at the structure of an IC, you'll note it consists of a
> set-constant instruction and a jump instruction.
> The jump can be patched atomically, but the set-constant cannot be part of
> the same transaction.
> The resulting race conditions are made innocuous with lots of fiddling.
> IC buffering helps do this.
> The IC's can be un-buffered (to run at speed) only at safepoints.
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150605/7cc806b3/attachment.html>