[foreign-memaccess] RFR 8237648: Add support for var handle adaptation

[Remi Forax]

Hi Maurizio,
you have forgotten checked exceptions,
if the adapters take a method handle as parameter, you can call a method that throws a checked exception.

It's not a big deal from the VM POV but unlike a MethodHandle.invoke*, get() and set() on a VarHandle do not declare to throw Throwable.

Obviously the solution is to get rid of checked exceptions in the language (did i already mention that ?).

Rémi

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Envoyé: Mercredi 22 Janvier 2020 15:35:27
> Objet: [foreign-memaccess] RFR 8237648: Add support for var handle adaptation

> Hi,
> this patch add support for some VarHandle adapters:
> 
> http://cr.openjdk.java.net/~mcimadamore/panama/8237648/
> 
> More specifically, the following adaptations are supported:
> 
> * filterValue
> * insertCoordinates
> * filterCoordinates
> * collectCoordinates
> * permuteCoordinates
> 
> This fixes an expressiveness mismatch between VarHandle and
> MethodHandles, as one could adapt MethodHandles, but cannot adapt
> VarHandles (the only way to do that is to map a VarHandle to a
> MethodHandle - using an AccessMode - and then use the MethodHandle).
> 
> To achieve this, only minimal surgery to j.l.invoke classes was
> required: the basic idea is to introduce a new class of VarHandle,
> namely IndirectVarHandle, which is merely an aggregate of a bunch of
> method handles, one per supported access modes. This means that we have
> now the ability to take apart an existing var handle into its MH
> components, adapt such components and repackage them into a brand new
> VarHandle.
> 
> To save unnecessary bytecode spinning, the component MethodHandles of an
> indirect VarHandle are only created on-demand - that is, if you only
> ever use the GET access mode - the machinery will not create the method
> handles for all the access modes which could be in principle be
> supported by the new var handle.
> 
> Since adapting a VarHandle might introduce changes in some of the
> coordinate types, I've disabled the VarHandleGuards fastpath for
> indirect handles, as the fast path does an invokeBasic and it skips any
> kind of type adaptation. While invokeBasic will detect e.g. a long vs.
> int mismatch, it does not detect (by design) a String vs. Runnable
> mismatch, so it is preferrable for indirect handles to always have an
> asType() adaptation. If the client is doing things "by the books" and
> using exact types in the VarHandle call, the asType() will do nothing
> and performances will not be negatively affected.
> 
> I also needed to tweak lambda form generation for var handles a bit, to
> obtain the direct var handle associated with an indirect handle before
> calling the linker method (otherwise we might end up the underlying
> VarHandle routine with the wrong VarHandle type).
> 
> I think overall, this implementation strategy proved to be flexible and
> relatively efficient - we can easily add as many adapters as we want,
> since we can build on the already rich MethodHandle combinator API.
> 
> Cheers
> Maurizio