RFR 8155258: VarHandle implementation improvements
Paul.Sandoz at oracle.com
Mon May 2 22:18:06 UTC 2016
The hotspot changes are really small. Is there is precedent in such cases to push through jdk9-dev rather than hs, thus speeding up the integration?
There are a bunch of improvements (mostly space/time):
1) By default a VarHandle does not hold its method types for access mode methods. Instead the erased types are held on VarForm (this shared across many VH instances) and are leveraged by the guard methods (see 4).
1.1) The non-erased method types are created on demand and cached (see 3).
2) Remove the use of ClassValue to hold VarForm instances. Each VarHandle implement holds its VarForm as a static instance. MemberNames to each access mode method implementation are still calculated on construction (this can be revisited to be lazy as a further issue).
3) A VarHandle caches invoker-based MethodHandles (access mode method type prefixed with VarHandle as the first parameter) to the corresponding MemberNames held on VarForm. Such handles are used by the VarHandle.toMethodHandle, by the guard methods (see 4), or general linkers/invokers.
4) The guard methods (on VarHandleGuards) were revamped to:
4.1) leverage the erased types in 1)
4.2) optimize for the void calling case (dropping the return value) when linking to a non-void access mode method. This is an edge case but avoids surprises (e.g. dropping the return value of a CompareAndExchange). This leverages a little known fact of invokehandle linking where it is safe to drop the return value (John assures me this is safe!), and required a slight tweak to hotspot for verification under fastdebug execution.
4.3) leverage the cached invoker method handle in 3) for the case where boxing/conversion is required, with an asType transformation. This is the non-optimal path, but is much better than before since the invoker method handle is a constant.
JPRT core and hotspot tests pass.
More information about the core-libs-dev