RFR (S): CR 8004318/JEP 171 Fences intrinsics

[Doug Lea]

On 12/03/12 19:45, Vitaly Davidovich wrote:
> Hi Doug,
>
> 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?


Yes. But by combining the boring essentially-free LOAD_STORE
with STORE_STORE, you avoid some anomalies when it does arise,
with no interesting effect in the normal use cases. (Hans Boehm once
had a couple of examples of why you want this at
http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/ but
I don't seem them there at the moment.)

One could argue to call these "acquireFence, "releaseFence"
and "volatileFence", just like hotspot does internally.
But experiences in several of the periodic discussions
about introducing Java-level versions (poke around
http://cs.oswego.edu/pipermail/concurrency-interest/)
led me to believe that more neutral names are less
prone to misunderstanding.

-Doug

>
> If you think load, store, and full fence is all that's required, then OK.
>
> Thanks
>
> Sent from my phone
>
> On Dec 3, 2012 6:57 PM, "Doug Lea" <dl at cs.oswego.edu <mailto:dl at cs.oswego.edu>>
> wrote:
>
>     On 12/03/12 17:40, Vitaly Davidovich wrote:
>
>         Hi Aleksey,
>
>         Why not have a bit more fine grained methods? OrderAccess in the VM has
>         operations matching JMM wording: loadload, storestore, loadstore, storeload.
>
>
>     By convention these days, in sparc-ese,
>     "loadFence"  => LOAD_LOAD|LOAD_STORE
>     "storeFence" => STORE_STORE|LOAD_STORE
>     "fullFence"  => STORE_LOAD|LOAD_LOAD|STORE___STORE|LOAD_STORE
>
>     Which maps exactly to internals in hotspot, and other VMs,
>     and most processors(*) and to the non-exotic C11/C++11 modes.
>     So there's  nothing  else you'd be tempted to support.
>
>     (*) except, famously, POWER and pre-ARMV8/ARM64 ARM, which
>     are always a bit of an adventure to map. Luckily, upcoming
>     ARMV8 is a breeze though.
>
>     -Doug
>
>
>