FTR: JVM Lang Summit presentation

[Paul Sandoz]

On Sep 3, 2014, at 5:28 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> 
> On 09/03/2014 04:44 PM, Paul Sandoz wrote:
>> On Sep 2, 2014, at 8:02 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> back from vacation too,
>>> slowly trying to anwser to a pile of emails ...
>>> 
>> I know how you feel :-)
> 
> A drawback of the 5 weeks of vacation policy in France :)
> 

C'est dur...


>> 
>> I experimented a bit with both of the above (see end of email for code) and each gets really rather close perf-wise and assembly-wise. I never quite realized how aggressive the JIT is at optimizing this area. Those casts can get reduced to almost no-ops (like the possibly redundant cast of the value in accessor DHMs). There are some redundant null-checks, as previously discussed on core-libs.
> 
> I use mh instead of plain code to avoid profile pollution.

I tried and failed to cause profile pollution in both cases with some simple examples. Same applies to VarHandles in the repo too.


> The profile is attached to the mh tree so you have as many profile sites as VarHandles instead of having one (or three in fact) profile site for all VarHandles.

W.r.t. VarHandles in the repo: IIUC invokehandle is a profile point (by default for 2 ref args) so the invokeExact side of VarHandles is covered. However, since VarHandles are not currently using LFs there is no type profiling of the args/params of the static methods.


> Maybe it's not needed, I don't know.

Since there are no specific operations performed on the instances of R and V is there anything gained by type profiling? How would the shape of the inlining differ for different ref receiver/value types?


> 
>> 
>> Are those casts always guaranteed to get optimized away if the handle is static final and an invocation on that handle is inlined?
> 
> good question, indeed.
> 

Oh, i was hoping you would know :-)


>> 
>> 
>>>> Any replacement of Unsafe in j.u.concurrent classes has to be almost, if not, as performant as that of direct Unsafe usage. It's proving quite useful to have something that works along similar fundamental lines (w.r.t. method invocation) that already gets quite close to Unsafe performance and from which we can evaluate and improve certain aspects.
>>> Anyway, i still think that the best way to write a safe compareAndSet is not to use a Varandle or any polymorphic signature method, but to let the compiler generate an invokedynamic with the right signature. The bootstrap method will verify the signature once (at link time) and so the generated method handle will only do downcasts to j.l.Object, something that the JIT will trivially consider as a no-op.
>>> 
>> I consider that as possible further steps, requiring some syntax bike shedding and a mechanism for how javac produces the indy call. Regardless we still need to evaluate the low-level plumbing.
> 
> but what you call a 'further step' removes the need to those castReference calls, making the low-level plumbing easier.
> 

I am already at the low-level pluming stage, in this respect there is no need at the moment to start syntax bashing and generating indy calls.

For example, a Class.cast on a value (not a receiver) is performed by both DHMs and VarHandles (which has an option to switch 'em off). Originally i thought they were for type profiling but i am not so sure now.

I need to perform an experiment turning those casts in accessor LFs of DMHs to asserts and running it through a bunch of stress tests. Same goes for VHs e.g. running JSR 166 loops tests.

If the cast is needed for DHMs we can work to optimise it so it does not leave redundant null-checks around. Otherwise we can remove it, and perhaps not bother optimising it unless it would be handy for other cases as well (like for those in the RefFieldVarHandle class).

Paul.