Resolution/translation of VarHandle.compareAndSet seems to conflict with JVMS/javadoc.

[John Rose]

On Jan 10, 2019, at 12:36 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> Bug report:
> https://bugs.openjdk.java.net/browse/JDK-8216520 <https://bugs.openjdk.java.net/browse/JDK-8216520>
> 
> This case probably hasn't gotten much attention because javac will never produce it.
> 
>> imho the call should still succeed with `void` as a return type (discarding the value). For other types, it would be more consistent with the spec/doc if the return type was dynamically cast to that of the descriptor, with possible CCE, but linking still succeeded.
> 
> Linking should succeed, but the run-time model these calls follow is 'invokeExact', not 'invoke': by design, they should fail immediately if there's a mismatch between expected and actual types, even if there's an easy adaptation (like dropping the result) from one to the other.

The JVMS mentions `invoke` as the immediate step taken by the JVM.
This confused me greatly when I read it, since it seems to promise
the sort of flexibility that is lacking here.  The problem boils down
to stacked MH invokers, one of which are exact, which makes the
whole stack inflexible.

I think the JVMS should be overhauled at this point.  I made some
notes to that effect on JDK-8216520.

— John