FTR: JVM Lang Summit presentation

Remi Forax forax at
Sat Aug 9 00:05:23 UTC 2014

On 08/09/2014 12:48 AM, John Rose wrote:
> On Aug 8, 2014, at 2:34 PM, Remi Forax <forax at 
> <mailto:forax at>> 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:
> <>
> 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.

(2am here, time to go to bed :)

More information about the valhalla-dev mailing list