RFR: 8254354: Add an asExact() VarHandle combinator [v2]

[Jorn Vernee]

On Fri, 23 Oct 2020 23:58:29 GMT, Jorn Vernee <jvernee at 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