FTR: JVM Lang Summit presentation

[John Rose]

On Aug 7, 2014, at 4:25 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>> slide 71:
>> I still think VarHandle is not a good idea. Having two way to represent roughly same thing, MethodHandle and VarHandle, is not a good idea.
> 
> In a perfect world, yes.  MethodHandle tried to model fields, it was a good first attempt, but it didn’t cover all the cases.  It can’t model accesses with (or without) fences; it can’t model atomic updates.  We could of course try to add more MH types to cover this, but the combinatorial explosion is large.  So, having explored the “continue down the MH path”, we discovered that the VarHandle path is richer and more suited to the problem.  Live and learn.

It seems to me there are serious usability problems with using MHs to build a VH API.  Given this:
   VarHandle vh = ... reify ObjType.fld ...;
   SomeType v0 = ..., v1 = ...;

we have:
   boolean z = vh.compareAndSet(obj, v0, v1);

versus:
   boolean z;
   try { z = vh.compareAndSet().invokeExact(obj, v0, v1); }
   catch (Exception e) { throw new AssertionError(e); }

And if we expose an intermediate MH, we would have to ensure that the MH would optimize away cleanly.

The VH prototype allows signature polymorphism to leak into some new types.  If we adopt the prototype as is, we will have to specify that leakage in the JLS and JVMS.  My biggest problem with the prototype is that I don't see a clean way to do that yet.

We can, of course, expose a MH at the bytecode level, under some suitable sugar.  And we can control its allocation cost if we are willing to use an invokedynamic instruction; then we would have a VH metafactory to produce a MH for each operation, for each signature.

One cost of using indy is that we would need a JLS change to define the sugary stuff that calls for the instruction.  That leads us back toward some variation of "obj.fld.volatile.compareAndSet(v0, v1)" or "vh.volatile.compareAndSet(obj, v0, v1)".

If we had fully polymorphic argument list abstraction, we could define vh.compareAndSet(...) as a method which called invokeExact internally.  That is a much bigger thing than ad hoc signature polymorphism, but possibly with a global payoff.  Hard to do.  Maybe method specialization would help, in a more modest way, to do similar things.

It feels to me that we might go back for some sugar in the end, as a way of minimizing deep spec. complexity by targeting indy.

But for now we are learning the most, the fastest, by using the VarHandle prototype.

— John