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

Vitaly Davidovich vitalyd at gmail.com
Tue Nov 27 15:59:48 EST 2012


Don't want to sidetrack this thread into Unsafe conversation, but it's also
used as (at least to my knowledge/use) as a poor man's Fences API, off heap
storage (latest trend in java "big data" segment), and some cpu-bound work
with what would've been java byte[] (e.g. bypass uneliminated range
checks).  Until JVM supports those use cases (even if they truly are
unsafe) and/or provides same perf, those usages won't go away.

Sent from my phone
On Nov 27, 2012 3:49 PM, "Jacy Odin Grannis" <jacyg at alumni.rice.edu> wrote:

> 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>
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> 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/27529e07/attachment.html>


More information about the Concurrency-interest mailing list