[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