On Fri, 23 Oct 2020 23:58:29 GMT, Jorn Vernee <[email protected]> wrote:
>> @PaulSandoz Thanks. I initially tested this with memory access VarHandles,
>> which don't erase the receiver type. e.g.
>>
>> MemoryLayout layout = MemoryLayout.ofSequence(10, JAVA_INT);
>> VarHandle vh = layout.varHandle(int.class,
>> MemoryLayout.PathElement.sequenceElement());
>> vh = vh.asExact();
>> try (MemorySegment segment = MemorySegment.allocateNative(layout)) {
>> for (int i = 0; i <10; i++) {
>> vh.set(segment.baseAddress(), i, i);
>> }
>> }
>>
>> Will result in:
>> Exception in thread "main" java.lang.invoke.WrongMethodTypeException:
>> expected (MemoryAddress,long,int)void but found (MemoryAddress,int,int)void
>> at
>> java.base/java.lang.invoke.VarHandleGuards.guard_LII_V(VarHandleGuards.java:915)
>> at main.Main.main(Main.java:18)
>>
>> Which led me to believe the approach would work for other reference types.
>> But, I suppose the MethodTypes fed to memaccess VarForms are non-erased as
>> an exception rather than a rule.
>>
>> I'll update the patch and sharpen the tests to check that the actual
>> expected type is correct (per the exception message).
>
> @PaulSandoz I've implemented your suggestion, by moving the `exact` flag to
> VarHandle itself. FWIW, the VH::accessModeType method took an AccessMode
> value as an argument, and the AccessDescriptor only stored the ordinal, so I
> added an `@Stable` array of values to AccessMode to map from ordinal to enum
> value. But, maybe it makes more sense to just store the AccessMode in the
> AccessDescriptor directly? (instead of the ordinal). Not sure what the
> original motivation was for only storing the ordinal.
>
> I've also sharpened the tests to check the exception message. Do you think
> the testing is sufficient? (Note that I did not add tests to the template
> files since only a select set of argument type conversions causes the WMTE
> we're looking for. So, that's why I created a new test file).
>
> FWIW, there seems to have been a bug in the implementation of
> IndirectVarHandle::accessModeTypeUncached, where it was using the VarHandle's
> type as the receiver argument (unlike all the other impls). I've fixed this
> by passing `null` instead, and also removed a workaround for this problem in
> VarHandles::maybeAdapt.
I've updated the javadoc, and added two benchmarks that show the existing
discrepancy between an exact and a generic use of a VarHandle, as well as
showing that an exact VarHandle is as fast as a generic VarHandle for an exact
invocation. (1 benchmark for normal Java field access, and 1 benchmark for the
foreign memory-access API).
-------------
PR: https://git.openjdk.java.net/jdk/pull/843
