InlineCacheBuffer + GuaranteedSafepointInterval
vitalyd at gmail.com
Fri Jun 5 17:17:07 UTC 2015
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...
More information about the hotspot-compiler-dev