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();