Draft j.u.c JEP

[Vitaly Davidovich]

I would prefer that Fences was a JDK API rather than being "hidden" inside
a VM one.  It is low level but there's nothing unsafe about it in the sense
of other APIs inside the Unsafe class, and it would be undesirable if one
had to jump through hoops to get access to it like we do for Unsafe today
(i.e. using reflection).

Sent from my phone
On Apr 22, 2012 6:02 AM, "Rémi Forax" <forax at univ-mlv.fr> wrote:

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