atom feed19 messages in edu.oswego.cs.concurrency-interestRe: [concurrency-interest] The Atomic...
FromSent OnAttachments
David M. LloydJul 14, 2012 11:01 am 
Doug LeaJul 14, 2012 11:17 am 
Stanimir SimeonoffJul 14, 2012 1:01 pm 
√iktor ҠlangJul 14, 2012 1:16 pm 
Rémi ForaxJul 14, 2012 2:20 pm 
Stanimir SimeonoffJul 14, 2012 2:58 pm 
Rémi ForaxJul 14, 2012 3:44 pm 
Doug LeaJul 15, 2012 3:37 am 
David HolmesJul 15, 2012 4:14 am 
√iktor ҠlangJul 15, 2012 8:22 am 
David M. LloydJul 15, 2012 9:19 am 
Jed Wesley-SmithJul 15, 2012 7:31 pm 
David HolmesJul 15, 2012 7:35 pm 
David M. LloydJul 15, 2012 7:43 pm 
David HolmesJul 15, 2012 7:52 pm 
Jason T. GreeneJul 20, 2012 11:42 am 
David HolmesJul 20, 2012 6:34 pm 
David M. LloydJul 22, 2012 1:47 pm 
Doug LeaJul 23, 2012 3:44 am 
Subject:Re: [concurrency-interest] The Atomic*FieldUpdater situation
From:Rémi Forax (for@univ-mlv.fr)
Date:Jul 14, 2012 3:44:00 pm
List:edu.oswego.cs.concurrency-interest

On 07/14/2012 11:58 PM, Stanimir Simeonoff wrote:

The next question is how to guarantee that the update value as the right type, otherwise you can corrupt the memory by putting a String in an Integer field (and you can't rely on generics for that).

Absolutely true, it's not needed to java.lang.Object, which is a start. C2 can eliminate redundant CHECKCAST since the class is a constant, dunno if Class.isAssignableFrom enjoys the same treatment. Hence, a simple class-gen will do the trick. Class-gen happen very often w/ reflect, so I do not consider it too special. Again, when System.ClassLoader is not present or the caller is from the bootstrap loader that class-gen can be omitted.

Class-gen is not as cool as it seems, it uses a lot of memory (bytecode + VM metadata) and classloader/class unloading is really tricky. MethodHandle should be used instead, but from perf point of view the JIT backend is still too young for this particular case, in fact, a MethodHandle.invoke() is exactly what we need. And I really hope that at some point in the future j.l.r.Method will be re-written to use method handles instead.

As a meta-comment, if they're was a way to trap Java method call to transform them into invokedynamic, all the problems mentioned above disappear because we will be in control of the callsite.

Since there would be a single subclass only instantiated in the JVM there would be no performance loss from multi-site invocations.

You don't care if there are several subclasses because you've put your AtomicReferenceFieldUpdater in a static final field.

True that, it can be proven it won't change, even if it's an interface.

Stanimir

Rémi