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

[Vitaly Davidovich]

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?

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> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121203/283afe40/attachment.html