FTR: JVM Lang Summit presentation

[Remi Forax]

On 09/04/2014 05:00 PM, Paul Sandoz wrote:
> On Sep 4, 2014, at 2:29 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> Not quite sure what you mean with the list example, but i have tested a static final instance of that RefFieldVarHandle class with calls to compareAndSet and multiple sub-classes of the receiver and value types.
>> The same call site called with different arguments or several calls with different arguments.
>> The former may lead to profile pollution, not the later.
> I tried the former.
>

[...]

>
>
>>> For the case of a poly sig method invocation the types are encoded at the call site, so for static final DHMs/VHs if the invocation is successful and gets inlined (which it should be forced to do when the calling method gets inlined) then it might be OK to remove the explicit cast on the value [*]
>> poly sig is a lot of things, it's the sum of
>> - a special type calculation rule in javac
>> - a variable arity signature
>> - a special (two in fact) semantics of calling for the VM
>>
> Yes, i happen to be taking advantage of all of these so a VH can cover multiple shapes and value kinds.

as i said earlier to John, we don't really need to have one code with 
multiple shapes,
here what we want is to have type specialization but we will not have it 
for 9 so
we can use overloads as we usually do to support strawman type 
specialization.

also note that we only need overloads for signature, if we use indy, we 
can have
several overloads but one implementation.

>
>
>> in our case, we only need the first item plus invokedynamic to avoid to have to specify another specific semantics in the JLS,
>> that's why I think that poly sig is not the best vehicle for implementing type safe compareAndSet and friends.
>>
> But... going full circle... we still need a mechanism to signal how that indy is encoded...

yes, you need an annotation and a meta annotation to specify the 
bootstrap method class and the bsm name.

>
> Paul.

Rémi