Lambda and JSR 292 method handle

[Rémi Forax]

Le 17/12/2009 15:37, Osvaldo Doederlein a écrit :
> When I complained about the "weight" and "bloat" of lambdas, I didn't 
> remember the issue of megamorphic callsites. Aggressive inlining would 
> be the only general exit for the problem. But then, it's much better 
> to not have this problems in the first place. The code size / permgen 
> is the less evil, as I don't see Java apps using enough closures to 
> have a problem in the scale of JRuby.
>
> Java already has (IMHO) too much reliance on JIT compilation. I've 
> long complained about other issues like the classfile's constant pool 
> failure to efficiently encode arrays and objects with constructors 
> simple enough for compile-time evaluation (ex.: new Point2D(0,0)) - 
> requiring bulky static initializers, which are of course executed in 
> interpreted mode. (I hope Jigsaw's new packaging format will address 
> this?) The result is the loading times that we all know and hate (and 
> that Sun is now pouring tremendous effort to reduce, for the good of a 
> client-side renaissance). Anyway, my (non-expert) view of 
> MethodHandles is that they are intrinsically more efficient than the 
> current alternatives, even before an advanced JIT (that we DON'T have 
> in the Client VM...) kicks in and performs all necessary incantations.

I remember Terrence Parr saying something similar about array and 65535 
bytecode size limit
at last JVM Summit.

>
> Neal said that a design/impl of lambdas over MethodHandles is 
> difficult and any such effort should start right now - that's bad news 
> because we don't even have a firm language design yet. I suppose that 
> in the worse case, we could change the implementation to benefit from 
> MethodHandles later down the road, in some JDK 7 Update XX. As long as 
> the new implementation won't have any observable effect in the 
> typesystem; I fear your item 4 implies the opposite?

Neal forget than method handle is one of the core feature of JSR 292 so 
all teams that
develop a dynamic language on top of the VM (at least JRuby, Jython aznd 
Groovy) already have
someone that have implemented a prototype of its favorite language using 
method handle.
This is not like starting from stratch.

But I agree with him that we need a specification and exorcise the devil 
(from the details :)

I don't belive changing the implementation after is possible,
you can prevent someone to use getClass().

>
> A+
> Osvaldo

Rémi