[concurrency-interest] @Contended (JEP-142)
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.
> 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 .
>> 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
>> 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.
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest