FTR: JVM Lang Summit presentation

[Remi Forax]

On 08/09/2014 12:48 AM, John Rose wrote:
> On Aug 8, 2014, at 2:34 PM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:

[...]

>> No, indy doesn't mean automatically syntactic sugar, you can have 
>> indy on methods on an API.
>
> Here's where we start having fun.
>
>> It's better to teach javac a new annotation, let say @Invokedynamic, 
>> that you put on methods. javac will generate an invokedynamic with a 
>> constant method handle to the implementation of the method if it 
>> exist (non abstract) as bootstrap argument instead of an invoke* when 
>> calling those methods.
>
> We could do that.  It would allow the user of the API to issue 
> unboxed, narrowed types to the call.  The constant method handle would 
> still have the boxed, widened types, unfortunately.
>
> To push the unboxed, narrowed types all the way into the invokeExact 
> would require that javac somehow emit a recipe for specializing the 
> implementation method to whatever types show up, at which point we are 
> doing this:
> http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html 
> <http://cr.openjdk.java.net/%7Ebriangoetz/valhalla/specialization.html>
>
> That urges the dependency question:  Should Unsafe removal wait until 
> we have method specialization?
> And/or:  Is there a small subset of full method specialization, 
> compatible with the full design, that would support VarHandle APIs?

While these two questions are very interesting , I believe we don't need 
method specialization for the specific case of compareAndSet, like 
Unsafe, we can have several overloads.

Rémi
(2am here, time to go to bed :)