InlineCacheBuffer + GuaranteedSafepointInterval (original) (raw)

Vitaly Davidovich 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... URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150605/7cc806b3/attachment.html>

More information about the hotspot-compiler-dev mailing list