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

[Maurizio Cimadamore]

On 25/01/2020 00:32, Paul Sandoz wrote:
>
>
>> On Jan 24, 2020, at 1:13 PM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com 
>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>
>> On 24/01/2020 17:44, Paul Sandoz wrote:
>>> MethodHandles
>>> --
>>>
>>> 5207      * If the filter returns {@code void}, the target must 
>>> accept all coordinates
>>> 5208      * not passed to the filter.
>>> ...
>>> 5235     public static VarHandle collectCoordinates(VarHandle 
>>> target, int pos, MethodHandle filter) {
>>>
>>> I am still uncertain of this use-case, and if we should allow it.
>>>
>>>
>>>> On Jan 23, 2020, at 6:07 AM, Maurizio Cimadamore 
>>>> <maurizio.cimadamore at oracle.com 
>>>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>>>
>>>> Here's a new webrev which addresses previous comments, and also 
>>>> adds the logic to check whether provided method handle filters are 
>>>> 'throwy' or not.
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8237648_v2/
>>>>
>>>> Regarding MethodHandles::throwException, I did few experiments and 
>>>> I concluded that it wasn't worth special casing. The MH returned by 
>>>> this method is, essentially, MethodHandlesImpl::throwException - 
>>>> which is declared to throw Throwable. So, the current logic will 
>>>> detect that, and issue an error.
>>>>
>>> Ok, the current logic looks good.  I think under the circumstances 
>>> it is reasonable to reject rather than automatically wrap (the 
>>> developer would have to do that).
>>
>> We could drop this use case.
>>
>
> My inclination would be to drop support for dropping coordinates.
Ok
>
>
>> We could similarly drop filterCoordinates and just retain 
>> collectArgument (which, if provided with unary filter behaves the 
>> same, right) ?
>>
>
> You mean filterCoordinates functionality can be composed from multiple 
> calls to collectArgument?
Yes
>
>
>> Also, should I move these combinators into the MemoryHandles class 
>> (in the incubating module) or do we prefer to leave them here in 
>> preparation for possible upstream to jdk/jdk?
>>
>
> My preference would be to eventually push them upstream.  But, let 
> them soak more in Panama during which they get some more usage.

Ok

Maurizio

>
> Paul.