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

[Maurizio Cimadamore]

Ugh - that's true. Perhaps the adapter handles should always be wrapped 
in a try/catch/rethrow unchecked?

Maurizio

On 22/01/2020 15:58, Remi Forax wrote:
> 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