Draft j.u.c JEP

[Rémi Forax]

On 04/21/2012 09:50 PM, Doug Lea wrote:
> On 04/21/12 13:10, Brian Goetz wrote:
>> My only concern is the mention of a "fences" API; I would think that 
>> this might
>> rise to the level of wanting its own JSR, since the memory model does 
>> not
>> necessarily provide for the all various relaxed consistency modes 
>> that such an
>> API would seem to imply, and might involve VM support.
>>
>
> Tying this to a JMM revision is a little scary: We know there
> are bugs (ranging from typos to unintended semantics to incompleteness)
> in the JMM. None of them are very interesting wrt 99.99999% of
> all java programs. Still, the sense is that any revision
> should fix these as well.  But some of these are not amenable
> to simple bandaids, but would require a major re-spec effort.
> In the mean time, we have introduced some methods (like
> AtomicX.lazySet) as well as those in the JDK7 Fences proposal
> that can ride on top of flawed underlying spec, in a way that
> doesn't introduce any further flaws, and so doesn't make eventual
> JMM re-spec any harder.
>
> When scoping out Fences for JDK7, I discussed the 3 minimal VM
> intrinsics methods to add with Hotspot and IBM J9 engineers. They
> were OK about doing it then (because it mainly entails just exposing
> some VM internals), so presumably still are, modulo
> scheduling effort to actually do it.
>
> The main questions are as always whether the potential benefits
> of exposing these methods to people who need them outweigh their
> relatively high potential for errors and uninterpretable effects.
> People have very strong view on both sides.
> (This doesn't impact us much inside java.util.concurrent
> because we can for the most part get the intended effects
> by directly using existing intrinsics.)
>
> Anyway, it's not clear we even want to have another discussion
> about introducing Fences. But I listed it because I think
> it is likely to come up again.
>
> -Doug
>

Given that fences is really low level, I'm not sure it's a good idea
to have a public API for them.
I would prefer to have a class sun.misc.Fences (or in sun.misc.Unsafe)
i.e. a class that is part of the VM API but not part of the JDK API.

Rémi