RFR JDK-8149644 Integrate VarHandles

[Remi Forax]

Hi all,

The comment in Infer 
  "//The return type for a polymorphic signature call"
should be updated to reflect the new implementation.

and this change in the way to do the inference (if the return type is not Object use the declared return type) is too ad hoc for me, 
we will need to do the same special case for the parameter types, soon, no ?

Rémi

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Paul Sandoz" <paul.sandoz at oracle.com>, "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "jdk9-dev"
> <jdk9-dev at openjdk.java.net>
> Envoyé: Lundi 15 Février 2016 14:58:11
> Objet: Re: RFR JDK-8149644 Integrate VarHandles
> 
> Langtools changes look ok to me. Would it make sense to file a follow up
> issue to add some tests in this area (i.e. bytecode tests using the
> classfile API) ?
> 
> Cheers
> Maurizio
> 
> On 11/02/16 15: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.
> 
>