[jmm-dev] Will the real memory read barrier please stand up?

[Martin Buchholz]

I'm struggling to educate myself about memory barriers, and I
discovered both Paul McKenney's awesome book and those newfangled
Unsafe fences in OpenJDK.  Paul's book says

"""A read barrier is a partial ordering on loads only; it is not
required to have any effect on stores."""

Meanwhile,  Unsafe.loadFence doc says,

"""Ensures lack of reordering of loads before the fence with loads or
stores after the fence."""

Spelunking in the hotspot sources, Unsafe.loadFence is implemented via
LoadFenceNode, which says:

""""Acquire" - no following ref can move before (but earlier refs can
follow, like an early Load stalled in cache)"""

So ... that's 3 different definitions?!  Further, the doc for
LoadFenceNode seems non-sensical to me - if following refs (load or
store) can cross the barrier backwards, how is that different in
effect from allowing preceding refs to cross the barrier forwards?
Both seem to allow any reordering at all?!  Should that have read
"""but earlier Stores (perhaps stalled in cache) can follow""" ?