[foreign-abi] RFR: 8238192: Reimplement MemoryAddress memory access handles on top of var handle combinators

[Jorn Vernee]

On Thu, 13 Feb 2020 13:16:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a continuation of the RFR here:
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-January/007366.html

It's unfortunate that AddressVarHandleGenerator still needs to be aware of the MemoryAddressProxy as a carrier. It would be nice if this wasn't the case, and it only knew about `long`, and we could handle the adaptation in places where we call JLI.memoryAddressViewVarHandle. The downside with the current setup is that AddressVarHandleGenerator silently changes MemoryAddressProxy to long, and expects code that is elsewhere (Utils::fixUpVarHandle) to apply the adaptation. These Seem prone to going out of sync...

For changing where the adaptation happens, the only problematic places seem to be MemoryHandles::withOffset and MemoryHandles::withStride. Since they use JLI.memoryAddressCarrier to find the carrier type. I also notice they re-wrap the direct VarHandle target, so any adaptation is discarded... I think we should require a direct VarHandle as a base for these methods, i.e. modify MethodHandleImpl::checkMemAccessHandle to throw if `handle.isDirect()` returns false, since we don't seem to be able to apply to re-apply the adaptations any ways (at least now). That would also mean that VarHandles with a MemoryAddress carrier would be disallowed for withOffset and withStride, and maybe that is  okay.

But, that should also allow use to remove knowledge about MemoryAddressProxy as a carrier from AddressVarHandleGenerator and instead handle the adaptation in MemoryHandles::varHandle and LayoutPath::dereferenceHandle instead, by requesting a VarHandle with 'long' as a carrier, and then applying the adaptation. Then all the adaptation happens in one place.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/19