A number of performance (space/time) improvements can be made to the current VarHandles implementation:

1) VarForm can hold erased method types for access mode methods. The non-erased method types held on VarHandle can be removed thus reducing footprint (such types can be created on-demand and cached if necessary)

2) VarHandle can create and cache, on-demand, invoker-based access mode MethodHandle on VarHandle.

3) Guard methods returning void can match a non-void returning access mode method with a corresponding cached, on-demand, erased void returning access mode method type.  The non-void returning member name can still be linked to as the VM will safely drop the return value. This means VH calls to compareAndExchange can drop the return type without any performance issue.

4) Guard methods can, when erased method types do not match, use the MethodHandle in 2) transformed, via MH.asType, using an invoker-based symbolic call site descriptor. Since the cached MethodHandle is used it will be a constant. There is still a performance hit for the non-constant asType transformed MH but there is also the performance hit for boxing/conversion, hence this path is not consider a priority compared to erased matched method types.

5) Static final VarForm instances can be directly held by each VarHandle implementation. This removes the need for ClassValue reducing dependencies and memory footprint.


For future consideration as follow on work:

1) All MemberName instances for access mode methods are calculated on static (or currently effectively static via ClassValue) initialization of a VarHandle implementation. Such instances can be calculated on-demand. A place holder constant value will be required to indicate unsupported access mode (or implementations should implement such modes throwing UOE).