On Fri, 23 Oct 2020 23:58:29 GMT, Jorn Vernee <jver...@openjdk.org> 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