<p dir="ltr">Hi Doug,</p>
<p dir="ltr">I was primarily thinking of storestore - on archs where stores and loads can be ordered orthogonally (and can be reordered architecturally), the additional loadstore in storeFence would be unnecessary (I.e. caller only wants storestore), no?</p>

<p dir="ltr">If you think load, store, and full fence is all that&#39;s required, then OK.</p>
<p dir="ltr">Thanks</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Dec 3, 2012 6:57 PM, &quot;Doug Lea&quot; &lt;<a href="mailto:dl@cs.oswego.edu">dl@cs.oswego.edu</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/03/12 17:40, Vitaly Davidovich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Aleksey,<br>
<br>
Why not have a bit more fine grained methods? OrderAccess in the VM has<br>
operations matching JMM wording: loadload, storestore, loadstore, storeload.<br>
</blockquote>
<br>
By convention these days, in sparc-ese,<br>
&quot;loadFence&quot;  =&gt; LOAD_LOAD|LOAD_STORE<br>
&quot;storeFence&quot; =&gt; STORE_STORE|LOAD_STORE<br>
&quot;fullFence&quot;  =&gt; STORE_LOAD|LOAD_LOAD|STORE_<u></u>STORE|LOAD_STORE<br>
<br>
Which maps exactly to internals in hotspot, and other VMs,<br>
and most processors(*) and to the non-exotic C11/C++11 modes.<br>
So there&#39;s  nothing  else you&#39;d be tempted to support.<br>
<br>
(*) except, famously, POWER and pre-ARMV8/ARM64 ARM, which<br>
are always a bit of an adventure to map. Luckily, upcoming<br>
ARMV8 is a breeze though.<br>
<br>
-Doug<br>
<br>
<br>
<br>
</blockquote></div>