[foreign-memaccess] RFR 8225172: Add way to create deref VarHandles without using the Layout API

[Maurizio Cimadamore]

Hi Jorn,
I too feel some of the tension you are talking about, but I'm quite 
opposed to a builder API such as the one you described.

Rather, what I'd be interested to explore, is whether we could built 
complex dereference expressions out  of simpler ones, using an approach 
similar to MethodHandle combinators. Let's assume that each memory 
access VH has an offset, denoted as O. Then it seems to me that there 
are only a bunch of moves we want to allow:

* obtain a memory address dereference for a given carrier type - this is 
the entry point VH, whose O = zero

* starting from a given memory address VH with offset O, obtain a new 
VH' whose O' =  O + C (where C is an argument to the combinator)

* starting from a given memory address VH with offset O, obtain a new 
one, called VH' whose offset O' = (S * N) + O (where S is an argument to 
the combinator - the scale - and N is a dynamic argument to VH' - the 
array index)

So, let's say I want to access the i32 in the layout below:

[5 : [ x32 i32 ] ]

What I'd do would be something like:

VarHandle handle = MemoryAddresses.dereferenceHandle(int.class); //(MA) -> I
handle = MemoryAddresses.offsetHandle(handle, 4); //(MA) -> I
handle = MemoryAddresses.elementHandle(handle, 8); //(MA, J) -> I


I think this is expressive enough to do what our API currently allows, 
and I kind of like that it gets there in a more primitive way (and very 
similar to how MH are constructed bottom up).


Whether I'd like to completely give up Layout/LayoutPath for something 
like this I'm not sure though. The ability of constructing a full memory 
layout and then obtaining a var handle from one of its path seems pretty 
good. I've written examples with this API where going down the Layout 
route immediately spotted latent alignment issues that were present in 
the Unsafe code that it replaced. So, while we can get there in a more 
primitive way, I'm not 100% sure of whether that means we should get rid 
of layouts too. At the very least, layouts are useful whenever there's 
some kind of size/alignment/offset computation to be done, which, with 
layout, can be expressed at a slightly higher level.

Maurizio




On 03/06/2019 17:46, Jorn Vernee wrote:
> Forgot to 'hg add' one file. See updated webrev: 
> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8225172/webrev.02/
>
> Thanks,
> Jorn
>
> Jorn Vernee schreef op 2019-06-03 18:38:
>> Hi,
>>
>> I've implemented an alternative way of creating memory access
>> VarHandles, which bypasses the Layout API. One reason for having such
>> an alternative API is that it offers users the opportunity to use
>> their own (pre-existing) layout APIs when creating VarHandles. This
>> mainly consists of a builder API called MemoryAccessVarHandleBuilder,
>> which can be used similarly to LayoutPath to construct a VarHandle.
>>
>> As a side effect I've removed the dependency on Layout/LayoutPath from
>> VarHandles::makeMemoryAddressViewHandle. I think this decoupling makes
>> this API point more suited to what's possible to do with memory access
>> VarHandles.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225172
>> Webrev: 
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8225172/webrev.01/
>>
>> Added tests are pretty minimal since the resulting VarHandle is
>> already tested by the existing tests using the Layout API.
>>
>> This also opens up the possibility of removing the Layout API
>> altogether if we wanted. Another TODO is adding a way to disable
>> alignment checking upon access (which would need changes to the
>> VarHandle impl classes I think).
>>
>> Thanks,
>> Jorn