[foreign-memaccess] RFR 8237648: Add support for var handle adaptation
Paul Sandoz
paul.sandoz at oracle.com
Sat Jan 25 00:32:31 UTC 2020
> On Jan 24, 2020, at 1:13 PM, Maurizio Cimadamore <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> 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.
> 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?
> 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.
Paul.
More information about the panama-dev
mailing list