RFR JDK-8149644 Integrate VarHandles

[Paul Sandoz]

> 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.

Paul..