FTR: JVM Lang Summit presentation

[Paul Sandoz]

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.


>> Interestingly it seems for static final instances of AtomicReferenceFieldUpdater the type propagation may be failing. Perhaps this is due to certain other checks getting in the way, such as explicit class pointer checks. (Also i dunno if it is also because the class's methods are abstract.)
> 
> I think, it's due to the fact that RefFieldVarHandle is declared in package java.lang.invoke which is special, the VM considers that the fields of classes of this package can not be changed by reflection thus the JIT can optimize through them.
> 

Oh! real final fields! I did not realize there was special treatment beyond that for specifically annotated stuff.

I cannot reproduce the optimizing effects outside of j.l.invoke. 

Do you know the area of hotspot where those optimizations are enforced?


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


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

Paul.