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

Roman Elizarov elizarov at devexperts.com
Wed Nov 28 13:05:54 EST 2012

I was talking about a completely different use-case. The key difference between annotations and sun.misc.Unsafe is that if your JVM does not support the annotation your code still works (albeit slower). There is no way to cover all uses of sun.misc.Unsafe with annotations, but many, many real-word uses of sun.misc.Unsafe could have been replaced by annotations. How often do you need a non-volatile read or write to a volatile variable? What do you do now? Your only choice now is to use sun.misc.Unsafe to mix and match volatile and non-volatile access. If could have used some-kind of annotation to describe your intention for a non-volatile access to a volatile variable instead. The particular version of JVM does not understand this particular annotation? No problem. Your code is still correct. And so on it goes. Just look at the places where you use sun.misc.Unsafe. 

-----Original Message-----
From: Doug Lea [mailto:dl at cs.oswego.edu] 
Sent: Wednesday, November 28, 2012 9:28 PM
To: Roman Elizarov
Cc: Concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] @Contended (JEP-142)

On 11/28/12 11:59, Roman Elizarov wrote:
> Going down this path we should have an @Unsafe public annotation, too. 
> In a trusted environment with supporting implementation the annotated 
> piece should use unsafe code for a better performance (just like a 
> @Contended annotation is basically a performance optimization hint). 
> Access to @Unsafe arrays  will skip range checks, @Unsafe 
> AtomicFieldUpdaters will skip type checks (and will works as fast as 
> with sun.misc.Unsafe but without the unpublic sun.misc part of it), etc.

(Here's where Aleksey's predicted metaphysical discussions kick in :-)

The main issue is that we cannot actually spec out the effects of @Contended, or most of the Unsafe operations in Java proper, that is using only constructs found in the JLS.
Those of us who use them are not really programming in Java, but instead in "JVMese". Any such @unsafe tag would immediately mean that you had escaped Java and moved into JVMese.

And seen in this way, if you are going to program in JVMese, then JVMese should be a better language! Automate the ugly Unsafe hacks. Support full macros. And so on.
A few academic colleagues and I have discussed actually creating such a language on and off for years. But life without it never seems to get quite bad enough to invest the time and work into this.


More information about the Concurrency-interest mailing list