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

[Maurizio Cimadamore]

Fixed and pushed. I've also updated the VH guard generator code in 
VarHandles.java

Maurizio

On 25/01/2020 02:20, Maurizio Cimadamore wrote:
>
> 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.