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é: Mardi 16 Février 2016 10:33:35
> Objet: Re: RFR JDK-8149644 Integrate VarHandles
> 
> 
> > On 15 Feb 2016, at 23:45, Remi Forax <forax at univ-mlv.fr> wrote:
> > 
> >>> 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.
> > 
> 
> Updated in place.
> 
> 
> >> 
> >> 
> >>> 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);
> > 
> 
> That ain’t gonna work because the shape is defined by the factory method
> producing the var handle, there could be zero or more coordinate arguments
> preceding zero or more explicit value arguments. We cannot declare a varargs
> parameter preceding other parameters and declaring Object[] is an awkward
> fit. It’s more that i would care to bite off in terms of tweaking the
> definition of signature-polymorphism.

ok, the actual meta-protocol used to create a varhandle doesn't allow anything other than a varargs as 'real' arguments,
but it's the tail waging the dog, this meta-protocol is an implementation artifact of the current way a varhandle is created.

anyway, i think it's too late to change this kind of things now,
given that the spec of what a polymorphic signature is has already changed, a future release may change this definition again.

> 
> Paul..
> 

Rémi