Lambda and JSR 292 method handle
forax at univ-mlv.fr
Thu Dec 17 06:58:09 PST 2009
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
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().
More information about the lambda-dev