RFR JDK-8149644 Integrate VarHandles

[Erik Joelsson]

Build part looks ok.

/Erik

On 2016-02-11 16:39, Paul Sandoz wrote:
> Hi,
>
> This is the implementation review request for VarHandles.
>
> Langtools:
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html
>
> Hotspot:
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html
>
> JDK:
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html
>
> The spec/API review is proceeding here [1].
>
> The patches depend on Unsafe changes [2] and ByteBuffer changes [3].
>
> Recent (as of today) JPRT runs for core and hotspot tests pass without failure. Many parts of the code have been soaking in the Valhalla repo for over a year, and it’s been soaking in the sandbox for quite and many a JPRT run was performed.
>
> It is planned to push through hs-comp as is the case for the dependent patches, and thus minimise any delays due to integration between forests.
>
>
> The Langtools changes are small. Tweaks were made to support updates to signature polymorphic methods and where may be located, in addition to supporting compilation of calls to MethodHandle.link*.
>
>
> The Hotspot changes are not very large. It’s mostly a matter of augmenting checks for MethodHandle to include that for VarHandle. It’s tempting to generalise the “invokehandle" invocation as i believe there are other use-cases where it might be useful, but i resisted temptation here. I wanted to focus on the minimal changes required.
>
>
> The JDK changes are more substantial, but a large proportion are new tests. The source compilation approach taken is to use templates, the same approach as for code in the nio package, to generate both implementation and test source code. The implementations are generated by the build, the tests are pre-generated. I believe the tests should have good coverage but we have yet to run any code coverage tool.
>
> The approach to invocation of VarHandle signature polymoprhic methods is slightly different to that of MethodHandles. I wanted to ensure that linking for the common cases avoids lambda form creation, compilation and therefore class spinning. That reduces start up costs and also potential circular dependencies that might be induced in the VM boot process if VarHandles are employed early on.
>
> For common basic (i.e. erased ref and widened primitive) method signatures, namely all those that matter for the efficient atomic operations there are pre-generated methods that would otherwise be generated from creating and compiling invoker lambda forms. Those methods reside on the VarHandleGuards class. When the VM makes an up call to MethodHandleNatives.linkMethod to link a call site then this up-called method will first check if an appropriate pre-generated method exists on VarHandleGuards and if so it links to that, otherwise it falls back to a method on a class generated from compiling a lambda form. For testing purposes there is a system property available to switch off this optimisation when linking [*].
>
> Each VarHandle instance of the same variable type produced from the same factory will share an underlying immutable instance of a VarForm that contains a set of MemberName instances, one for each implementation of a signature polymorphic method (a value of null means unsupported). The invoke methods (on VarHandleGuards or on lambda forms) will statically link to such MemberName instances using a call to MethodHandle.linkToStatic.
>
> There are a couple of TODOs in comments, those are all on non-critical code paths and i plan to chase them up afterwards.
>
> C1 does not support constant folding for @Stable arrays hence why in certain cases we have exploded stuff into fields that are operated on using if/else loops. We can simplify such code if/when C1 support is added.
>
>
> Thanks,
> Paul.
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038150.html
> [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020953.html
>       http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021514.html
> [3] http://mail.openjdk.java.net/pipermail/nio-dev/2016-February/003535.html
>
> [*] This technique might be useful for common signatures of MH invokers to reduce associated costs of lambda form creation and compilation in the interim of something better.