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

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Envoyé: Mercredi 22 Janvier 2020 17:57:22
> Objet: Re: [foreign-memaccess] RFR 8237648: Add support for var handle adaptation

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

yes, that's ugly either all Throwables that are not Error and RuntimeException has to be wrapped into something like a UndeclaredCheckedException or you reject all method handles that throws a checked exception but that seems wrong given it's a pervasive change to track if a mh was created on a method that throw a checked exception or not, it goes against the idea that a mh has the same semantics as the bytecode in the VM. There are another couple of options, one using a time machine :) 

> 
> Maurizio

Rémi

> 
> 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