[concurrency-interest] @Contended (JEP-142)

Jacy Odin Grannis jacyg at alumni.rice.edu
Tue Nov 27 15:45:59 EST 2012


I agree with finding the placement in sun.misc a bit off-putting.  If I'm
writing a shared library that might get used across VMs, it would be much
friendlier to be able to use an annotation which has optional VM support,
say, so that if users use the library on a VM which supports the
annotation, they get the benefit...and more importantly, if the VM they are
using doesn't currently support, they might later get the benefit when a
newer release of that VM adds support.  Instead, by putting it in sun.misc,
it forces library writers to make more difficult choices.

As far as Unsafe goes...I think it's problematic that it does get used as
much as it does.  The Atomic FieldUpdaters exist, the big argument against
them seems to be the parameter safety checks.  Given that they are
implemented with an internal class, I think you could replace a lot of
Unsafe usage if you simply added a new newUpdater() factory method which
had an additional boolean argument to allow construction of a FieldUpdater
which didn't include the checks.  So instead of just having
AtomicReferenceFieldUpdaterImpl, you'd also have a private
AtomicReferenceFieldUpdaterUnsafeImpl which skipped the parameter checks.
Could people screw themselves?  Yeah, but no more than they can by using
Unsafe curently...but they could write more portable code, which should
surely be seen as a good thing.

jacy


On Tue, Nov 27, 2012 at 2:28 PM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 27/11/2012 18:25, Doug Lea wrote:
>
>>
>> But you ship code with sun.misc.Unsafe :-)
>> As it stands, sun.misc is the place in which non-standard but
>> universally implemented, platform related, expert-user-only APIs reside.
>> So seems to be the least controversial home for it. The main
>> difference is that you won't be able to treat is as assumed to
>> be present until JDK8. But this is also true of some other
>> things like upcoming getAndAdd intrinisification.
>>
>> I'd conclude by saying that other suggestions are welcome, but
>> they aren't welcome by me :-) This seems like the only
>> packaging that no one feels like they must try to veto .
>>
>> -Doug
>>
> I think it's time to consider a new namespace for this and what might
> follow. As the intention is not to include it in Java SE then something
> like jdk.vm.Contended might be a candidate to think about. I also think
> it's time to think adding a "supported" jdk.vm.Unsafe but that's a bigger
> discussion.
>
> One thing about @Contended in sun.misc is that I assume it's not going to
> work when running with a security manager. It might also make it harder to
> move to modules with strongly enforced boundaries as modules will only
> export "supported" APIs. Even without modules then I assume that
> expert-users would at least have some aversion to using sun.* APIs and the
> javac warning that goes along with it.
>
> -Alan.
>
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121127/e7a63edf/attachment-0001.html>


More information about the Concurrency-interest mailing list