Mercurial > hg > graal-compiler
diff src/cpu/x86/vm/assembler_x86.hpp @ 671:d0994e5bebce
6822204: volatile fences should prefer lock:addl to actual mfence instructions
Reviewed-by: kvn, phh
author | never |
---|---|
date | Thu, 26 Mar 2009 14:31:45 -0700 |
parents | c89f86385056 |
children | fbde8ec322d0 |
line wrap: on
line diff
--- a/src/cpu/x86/vm/assembler_x86.hpp Tue Mar 24 15:09:52 2009 -0700 +++ b/src/cpu/x86/vm/assembler_x86.hpp Thu Mar 26 14:31:45 2009 -0700 @@ -1068,15 +1068,23 @@ LoadLoad = 1 << 0 }; - // Serializes memory. + // Serializes memory and blows flags void membar(Membar_mask_bits order_constraint) { - // We only have to handle StoreLoad and LoadLoad - if (order_constraint & StoreLoad) { - // MFENCE subsumes LFENCE - mfence(); - } /* [jk] not needed currently: else if (order_constraint & LoadLoad) { - lfence(); - } */ + if (os::is_MP()) { + // We only have to handle StoreLoad + if (order_constraint & StoreLoad) { + // All usable chips support "locked" instructions which suffice + // as barriers, and are much faster than the alternative of + // using cpuid instruction. We use here a locked add [esp],0. + // This is conveniently otherwise a no-op except for blowing + // flags. + // Any change to this code may need to revisit other places in + // the code where this idiom is used, in particular the + // orderAccess code. + lock(); + addl(Address(rsp, 0), 0);// Assert the lock# signal here + } + } } void mfence();