Method references with types [Re: lambda syntax tutorial]

[Rémi Forax]

Le 06/08/2010 21:46, Nathan Bryant a écrit :
> 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.

I'm not a scala god but it seems that most of the scala loops are 
megamorphic.


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

That's weird, there is a special trick in the VM to handle Integer.valueOf()
see in opto/memnode.cpp, the function named eliminate_autobox.

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

Rémi

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