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

Reply via email to