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

[Aleksey Shipilev]

On 12/05/2012 07:50 PM, Kirk Pepperdine wrote:
> To my knowledge, n the history of the JDK.. no public exposed API
> has ever been cleaned up. Once exposed it will be used and once used
> it will be impossible to back off of it. Thus prudence needs to be 
> preferred over expedience. What makes you believe that you will be 
> able to clean Unsafe in the future?

The definition of "publicly exposed API" is very blunt when it comes to
Unsafe. Unsafe is internal, and as such is deliberately unsupported.
Otherwise, you end up cornering yourself into "you can't really add this
internal thingy, because that becomes the part of exposed APIs"
extending to each and any class in JDK internals, which pretty much
seals off JDK libraries from *any* internal change.

> The VM has proven time and time again that being adaptive to the run 
> time has provided many many benefits that are not reachable by 
> average developers.

Noble goal. Now, can we do something about it in realistic timeframe?
"Average users" don't actually care about all this fences stuff, but the
do care about the performance of library classes about to rely on fences
to ensure correctness (e.g. JDK8-ish SequenceLock).

>> In fact, for fences, it was on the table for at least 3 years, and 
>> no better+practical approach emerged. That is why I get sincerely 
>> amused when somebody wants to have the discussion about fences 
>> again, and get double amused when exposing the intrinsics to 
>> out-of-band internal API somehow promotes to "omg, that breaks 
>> Java" stunts.
> 
> Sorry to say this but I find this attitude both offensive and
> counter productive to community building.

Sorry to hear my directness and leaking discomfort having this
discussion is again looked offensive. Switching back to nice guy mode... :I

I find the discussion about exposing intrinsics to out-of-band class
unnecessarily extended to the discussion on the Java language. While the
goal to accommodate fences into Java language is worth discussing, it is
not the part of this JEP. This JEP is about exposing these primitives to
library developers who sorely need these intrinsics now, without making
any promises for the general crowd. These intrinsics are unarguably
unsafe, and that is why these are not even conceived to be used in
"safe" Java land.

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

Everyone does. In fact, it had popped out countless times, so that I'm
getting mad every time I hear it anew (I wonder how Doug even keeps his
sanity, must be some interesting contract sealed with blood).

You can emulate fences by reading/writing from/to static volatile field,
and make your VM intrinsify the methods doing the read/writes, and
remove the memory opts, leaving only the barriers. This would be
approachable for the general public, because it has the clear semantics
in terms of existing JMM ("the memory effects as if reading/writing
global volatile field"). This will eventually sinkhole to "no can do:
users will misuse these", and we will get back to square one to Unsafe
proposal.

-Aleksey.