RFR (S): CR 8004318/JEP 171 Fences intrinsics
vitalyd at gmail.com
Mon Dec 3 16:45:41 PST 2012
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.
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,
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev