[concurrency-interest] CAS using a MethodHandle

Charles Oliver Nutter headius at headius.com
Mon Dec 19 18:54:10 EST 2011


Oops, this went only to Rémi...re-copying conc list.

 On Mon, Dec 19, 2011 at 12:28 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> Hi all,
> Some time ago, I said that we should try to use a MethodHandle instead of an
> Atomic*FieldUpdater and let the VM inline the method handle so there should
> be no cost (or a little one) compared to directly calling
> unsafe.compareAndSwapObject.
>
> The following code does exactly that, I have also include a small test that
> just demonstrates that it works.
> Because I'm neither a benchmark expert nor an assembler expert, I've just
> checked that the method handle is fully inlined by the JIT and that the
> generated code seems to don't have more code than it should.

FWIW, JRuby's using this pattern heavily to optimize several
volatile/atomic operations:

* When a class is modified, any code that has cached methods from that
class gets deoptimized. This avoids repeatedly pinging a volatile
serial number.
* When a constant is defined anywhere in the system, code that has
cached constants is deoptimized. This makes Ruby's constants
*actually* perform like constants...and in fact, they're faster and
optimize better than finals.

SwitchPoint is an incredibly sharp tool, but Rémi's example shows it
can do things that were previously impossible. I actually mocked up my
own SwitchPoint-based atomic updater last week...it's fun to play with
:)

- Charlie



More information about the Concurrency-interest mailing list