[concurrency-interest] CAS using a MethodHandle

Rémi Forax forax at univ-mlv.fr
Mon Dec 19 19:49:20 EST 2011


On 12/20/2011 12:58 AM, Charles Oliver Nutter wrote:
> On Mon, Dec 19, 2011 at 4:14 PM, Roman Elizarov<elizarov at devexperts.com>  wrote:
>> Is it possible to implement Atomic*FieldUpdater on top of the MethodHandle to Unsafe?
>> That is, place all checks in Atomic*FieldUpdater factory method, keep method handle(s) in final fields of updater and trivially implement CAS and other updater methods via method handle(s)? Can we thus get the best of two worlds -- type-safe and backwards-compatible API and better performance? // I assume, that HotSpot will be able to inline it all the way through, will not it?
> It wouldn't necessarily inline, since the code inside
> AtomicReferenceFieldUpdater would be polymorphic (i.e. a different
> MethodHandle for each updater, but all called through the same path).
>
> If it were possible to emit an invokedynamic into the Java code,
> though, you could have an inlinable path:
>
> invokedynamic ->  MH for CAS ->  Unsafe.CAS

If we had a way to tell the compiler to generate an invokedynamic 
instead of an invokesomething,
then we will be able to control more closely how the things are optimized.
It will simplify an insane number of problem like proxies, aop, O/R 
mapping, SQL mapping*, etc.

* you can by example create the SQL statement corresponding to a String 
and inject it in place of the string
   if the string is constant.

>
> Another option would be adding a method to AtomicReferenceFieldUpdater
> that returns a MethodHandle for some of those opeerations...something
> like
>
> MethodHandle handle = ARFU.getCompareAndSwapHandle();
> ...
> boolean result = (boolean)handle.invokeExact(this, expected, value);
>
> I believe that would inline all the way through to Unsafe.

if the two lines of code are part of the same inlining blob, which is 
sometimes not easy to predict.
I also think that there is perhaps still a perf bug in this case with 
the current version of Hotspot
because the escape analysis may not see through invokeExact.

>
> - Charlie

Rémi



More information about the Concurrency-interest mailing list