FTR: JVM Lang Summit presentation

[Remi Forax]

On 09/03/2014 06:26 PM, Paul Sandoz wrote:
> 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.



Do you have tested to call the same VarHandle.compareAndSet with 
different classes like by example if you have a linked list with two 
classes as possible implementation of a link ?

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

You still ask to do classchecks on instances of R and V,
if the JIT is always able to do type propagation from the call site, 
then it can remove them,
if type propagation fail, it will relies on type profiling, if there is 
only one profile, the classcheck will be compiled to a cheap pointer check,
if there is type pollution, the generated code may start to be expensive 
(relatively).

>
>
>>> 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 :-)

I don't know what @ForceInline does exactly, i.e. is it enough to 
guarantee type propagation or not ?

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

I'm not talking about syntax but semantics.
As I wrote earlier, I don't think it's a good idea to have a DSL inside 
Java especially when you can solve the problem using an API.
Talking about semantics, the question is: does the type of the arguments 
are erased to Object or not ?
If the types of the argument are erased, you have to explain to the JIT 
that you want to remove the checkcasts,
if the types of the argument are not erased, the is no problem.

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

Rémi