+Rodolph
https://codereview.chromium.org/284153004/diff/1/src/ic.cc
File src/ic.cc (right):
https://codereview.chromium.org/284153004/diff/1/src/ic.cc#newcode866
src/ic.cc:866: set_target(*pre_monomorphic_stub(), SKIP_ICACHE_FLUSH);
On 2014/05/16 08:38:48, ulan wrote:
I am not sure whether this is safe. We are leaving icache in an
inconsistent
state. Do ARM, ARM64, MIPS guarantee some kind of "atomicity" in this
case? I
mean
1) either the old instruction is completely executed
2) or the new instruction is completely executed?
Thus is a good point which I was worried about. Given that the
instructions are 4 byte writes to 4 byte aligned addresses, I think the
updates are guaranteed to be atomic, but I'm not sure (maybe we should
use an Atomic32 NoBarrier_Store?).
I've updated this to ensure that it only does this update if both the
instructions updated are on the same cache line, and then perform a
MemoryBarrier, which I think should ensure the CPU either sees the the
whole old instruction sequence, or the whole new instruction sequence.
Rodolph, is there any guarantees on Arm which we can exploit here,
assuming we don't care whether we execute the old instructions or the
new instructions, but want to ensure we don't execute a mix of old and
new?
https://codereview.chromium.org/284153004/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
