[foreign-abi] RFR 8236004: Memory access var handles should support MemoryAddress carrier
Paul Sandoz
paul.sandoz at oracle.com
Tue Dec 17 01:07:10 UTC 2019
Looking good but sorry I read the code incorrectly and confused myself and lead you down the wrong path as a result. Still swapping back all this stuff :-)
I originally thought the VarHandle impls were incorrect generating the accessModeTypeUncached methods returning method types with erased components.
I think we need to revert back to Object in X-VarHandleMemoryAddressView.java.template
@ForceInline
- static MemoryAddressProxy checkAddress(Object obb, long offset, long length, boolean ro) {
- MemoryAddressProxy oo = (MemoryAddressProxy)Objects.requireNonNull(obb);
+ static MemoryAddressProxy checkAddress(MemoryAddressProxy obb, long offset, long length, boolean ro) {
+ MemoryAddressProxy oo = Objects.requireNonNull(obb);
oo.checkAccess(offset, length, ro);
return oo;
}
@ForceInline
- static $type$ getVolatile0(VarHandleMemoryAddressBase handle, Object obb, long base) {
+ static $type$ getVolatile0(VarHandleMemoryAddressBase handle, MemoryAddressProxy obb, long base) {
MemoryAddressProxy bb = checkAddress(obb, base, handle.length, true);
return convEndian(handle.be,
UNSAFE.get$RawType$Volatile(
bb.unsafeGetBase(),
offset(bb, base, handle.alignment)));
}
Although it's fixed in your case the VarHandles linking machinery operates on erased signatures. Now I recall one major reason why: it's so that invocation behaves similar to MH.invoke rather than MH.invokeExtact, thus making it easier to pass subtypes without having to declare an explicit cast at the call site (which would have made it far more painful for adoption). As a consequence the VarHandle implementations must perform checks on ref types.
Apologies for the mis up,
Paul.
> On Dec 16, 2019, at 7:33 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
> Hi,
> this patch adds support for MemoryAddress as a possible carrier for memory access var handles
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8236004_v2/
>
> To allow for safe creation of memory addresses, the new var handles use the same trick we used for 'forged' addresses - that is, they return an address based on the Nothing segment.
>
> The patch tweaks var handle generation a bit in order to generate slightly sharper (unerased) signatures; after some chats with Paul it was clear that the fact that Object was being used as the VarHandle 'receiver' param was more of a leftover from normal VarHandle code (e.g. field access), where using Object allows us to share the var forms more easily. But memory access VarHandles always end up using MemoryAddress as a receiver - so there's no possible gain there, and the code becomes cleaner by using the sharper type, so it seems like a good deal.
>
> Maurizio
>
>
More information about the panama-dev
mailing list