Method references with types [Re: lambda syntax tutorial]

[Nathan Bryant]

Rémi,

In the Scala microbenchmarks I was playing with most recently, I found some big performance loss in cases where the JVM couldn't remove boxing; this is in trivial, single-thread, monomorphic situations where I would have expected inlining to take place. Google searching has led me to believe the JVM has problems with Integer.valueOf() instead of new Integer(), but that is not enough to explain the results. So if optimizations are part of the argument against function types, I don't think the optimizations are quite there yet.

I also found Java's collection traversals to be much faster than Scala's for the cases I tried.

-----Original Message-----
From: Rémi Forax [mailto:forax at univ-mlv.fr] 
Sent: Friday, August 06, 2010 11:31 AM
To: Nathan Bryant
Cc: Paul Benedict; lambda-dev at openjdk.java.net
Subject: Re: Method references with types [Re: lambda syntax tutorial]

Le 06/08/2010 00:09, Nathan Bryant a écrit :
>
> Remi Forax wrote:
>
>    
>> Also note that even if you use an Integer in the signature, the VM
>> is already able to not do the corresponding boxing
>> (see one of the last mail of Fredrik on this list).
>>      
> The PowerPoint I saw dealt with adding function types to the VM as basically a type annotation on MethodHandle, which would be renamed Function. (A proposal I support, as it makes MethodHandles a first class citizen, not something that is only really useful to compiler backend writers.)
>    

I was refering to the demo page 30 of the slides,
This example in particular:
   Integer c = mh.<Integer>invoke((Integer)3, 3);
There is a boxing and this boxing can be removed because
the method reference is declared with an int.

MethodHandle by itself is not very useful in plain old Java because it's 
not typesafe.
method handle is a kind of how the reflection API should have been done,
so it's truly faster than reflection but like reflection it's not typesafe.

I see lambda SAM conversion as a thin typesafe wrapper on top of method 
handle.
We get the backward compatibility with most of the legacy code
that deal with SAM types in the same move.
But we lost function types during the battle :(

> In this case, the compiler is able to remove the primitives. However, the more general box/unbox elimination optimization has not been implemented yet either in JDK7 or in any publically released version of JRockit. It also depends on the ability to inline.
>    

jdk7 has escape analysis and you're right it depends if the callsite is 
monomorphic and inlinable.

Rémi