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

[Doug Lea]

On 11/19/2014 02:12 PM, Martin Buchholz wrote:
> I'm struggling to educate myself about memory barriers,..

Catching up after being diverted with other things...
here are a few minor footnotes to other replies:

Terminology is not very standard. To maximize clarity,
I use "fence" (vs "barrier") to reduce confusion vs
garbage-collection barriers.
And "load" (vs "read") to reduce confusion vs IO.
Similarly for "store" vs "write".
And when applicable, Sparc-ese beforeAfter designations:
LoadLoad, LoadStore, StoreStore, StoreLoad and their
combinations. (Although there can be fence types that
don't nicely fall into any of these categories.)

>
> """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."""

This is a [LoadLoad|LoadStore] fence, also known as
a "load acquire" fence, which is sometimes (including
inside hotspot) just called a "load fence" because it is the
only kind of Load* fence that is ever wanted. The hotspot
intrinsic name name was chosen to match this existing
internal convention, at the expense of external confusion.
(It's not the only such case with intrinsics.)

>
> Spelunking in the hotspot sources, Unsafe.loadFence is implemented via
> LoadFenceNode, which says:
>
> [...confusing things...]

I think most of the internal docs/comments remain from
pre-JDK5. It might be a good idea to update them.

-Doug