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

[Doug Lea]

On 12/05/12 10:50, Kirk Pepperdine wrote:

> their applications are fighting with the hardware... That said, I really
> wished that we had a better... safer way to achieve the same effect than
> exposing people to unsafe.
>

Of course, we all do. Mere wishing has had the effect of not
exposing these obviously-needed intrinsics for 11 years now.
(I regret letting people talk me out of exposing them
back when I was first involved in the discussions of the
semantics of c2 acquire/release/volatile membars.) And the past
decade's worth of discussion, periodically re-raised
on concurrency-interest list 
(http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest) usually boil 
down to: (1) We
cannot expose these methods because we cannot spec them
without overhauling the JMM, and (2) We don't like it
that some people will misuse them. I'm sure that
if you had a better solution for a better outcome, you
would have posted it there :-)

So, the current @Contended and Fences proposals concede
these arguments. They do not provide support in Java(tm) the
language or platform, but are available via an
unstandardized API on openJDK and any other JVM
that wants to offer this functionality. My intent
was that these concessions should then allow this
support to at least be in place for use now
inside core libraries, and so that when the more
controversial aspects are resolved, we don't
stall yet again  on the implementation side.

-Doug