RFR JDK-8149644 Integrate VarHandles

[Remi Forax]

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "jdk9-dev" <jdk9-dev at openjdk.java.net>, "hotspot-dev developers" <hotspot-dev at openjdk.java.net>
> Envoyé: Lundi 15 Février 2016 17:37:32
> Objet: Re: RFR JDK-8149644 Integrate VarHandles
> 
> Hi Remi,
> 
> > On 15 Feb 2016, at 15:58, Remi Forax <forax at univ-mlv.fr> wrote:
> > 
> > Hi all,
> > 
> > The comment in Infer
> >  "//The return type for a polymorphic signature call"
> > should be updated to reflect the new implementation.
> > 
> 
> That comment should really be folded into the first if block.
> 
> I could do that as follows:
> 
>   // The return type of the polymorphic signature is polymorphic,
>   // and is computed from the ...
> 
> And then in the else block
> 
>   // The return type of the polymorphic signature is fixed (not polymorphic)
> 
> ?

yes, good idea.

> 
> 
> > 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
> > ?
> > 
> 
> Do you have any use-cases in mind?
> 
> Rather than ad-hoc i would argue instead the enhancement of
> signature-polymorphic methods is limited to that required by the current
> use-cases.
> 
> IIRC I did pull on that more significantly at one point when i had sub-types
> for array handles since the index need not be polymorphic. But we dialled
> back from that approach.

as you said one use case is to be able to fix an index, but perhaps a more interesting case is to be able to bound the number of parameters,
by example for compareAndSet
  boolean compareAndSet(Object expected, Object value)
is better than
  boolean compareAndSet(Object... args);

> 
> Paul.
> 

Rémi