[concurrency-interest] @Contended (JEP-142)
dl at cs.oswego.edu
Wed Nov 28 12:28:00 EST 2012
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