--- a/graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/MemoryBarriers.java	Thu Feb 19 15:44:05 2015 +0100
+++ b/graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/MemoryBarriers.java	Thu Feb 19 16:15:56 2015 +0100
@@ -24,7 +24,7 @@
 
 /**
  * Constants and intrinsic definition for memory barriers.
- * 
+ *
  * The documentation for each constant is taken from Doug Lea's <a
  * href="http://gee.cs.oswego.edu/dl/jmm/cookbook.html">The JSR-133 Cookbook for Compiler
  * Writers</a>.
@@ -32,14 +32,14 @@
  * The {@code JMM_*} constants capture the memory barriers necessary to implement the Java Memory
  * Model with respect to volatile field accesses. Their values are explained by this comment from
  * templateTable_i486.cpp in the HotSpot source code:
- * 
+ *
  * <pre>
  * Volatile variables demand their effects be made known to all CPU's in
  * order.  Store buffers on most chips allow reads &amp; writes to reorder; the
  * JMM's ReadAfterWrite.java test fails in -Xint mode without some kind of
  * memory barrier (i.e., it's not sufficient that the interpreter does not
  * reorder volatile references, the hardware also must not reorder them).
- * 
+ *
  * According to the new Java Memory Model (JMM):
  * (1) All volatiles are serialized wrt to each other.
  * ALSO reads &amp; writes act as acquire &amp; release, so:
@@ -50,7 +50,7 @@
  * that happen BEFORE the write float down to after the write.  It's OK for
  * non-volatile memory refs that happen after the volatile write to float up
  * before it.
- * 
+ *
  * We only put in barriers around volatile refs (they are expensive), not
  * _between_ memory refs (which would require us to track the flavor of the
  * previous memory refs).  Requirements (2) and (3) require some barriers