Messages per Month
|David M. Lloyd||Jul 14, 2012 11:01 am|
|Doug Lea||Jul 14, 2012 11:17 am|
|Stanimir Simeonoff||Jul 14, 2012 1:01 pm|
|√iktor Ҡlang||Jul 14, 2012 1:16 pm|
|Rémi Forax||Jul 14, 2012 2:20 pm|
|Stanimir Simeonoff||Jul 14, 2012 2:58 pm|
|Rémi Forax||Jul 14, 2012 3:44 pm|
|Doug Lea||Jul 15, 2012 3:37 am|
|David Holmes||Jul 15, 2012 4:14 am|
|√iktor Ҡlang||Jul 15, 2012 8:22 am|
|David M. Lloyd||Jul 15, 2012 9:19 am|
|Jed Wesley-Smith||Jul 15, 2012 7:31 pm|
|David Holmes||Jul 15, 2012 7:35 pm|
|David M. Lloyd||Jul 15, 2012 7:43 pm|
|David Holmes||Jul 15, 2012 7:52 pm|
|Jason T. Greene||Jul 20, 2012 11:42 am|
|David Holmes||Jul 20, 2012 6:34 pm|
|David M. Lloyd||Jul 22, 2012 1:47 pm|
|Doug Lea||Jul 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|
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.
_______________________________________________ Concurrency-interest mailing list Conc...@cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest