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

Doug Lea dl at cs.oswego.edu
Wed Dec 5 09:08:42 PST 2012

On 12/05/12 11:14, Doug Lea wrote:
> Of course, we all do. Mere wishing has had the effect of not
> exposing these obviously-needed intrinsics for 11 years now.

Oh, one more FAQ that is a little obscure in the JEP:
If I've been living without these for 11 years, what's
wrong with delaying this for another release or two?

I have so far been able to twist designs/code to
use volatiles and/or fenced access intrinsics to combine fences
with access. But JDK8 is the first release where the
specs of at least one component (StampedLock)
relies on a lack of reordering that is allowed by the JMM for
volatiles. As it turns out, this reordering does not occur
when you use getLongVolatile in hotpot instead of a plain
volatile read, but this is just an accidental fact that
is not mentioned anywhere. I really do not want to depend
on this in released code that will run on multiple JVMs,
relying on varying interpretation of the non-existent
getLongVolatile spec. Using a plain Unsafe.loadFence here will
clearly suffice: Even if the fence intrinsics remain as-yet
unformalized, the intent is clear.

So this was a good enough reason to masochistically
go through this process :-)


More information about the hotspot-compiler-dev mailing list