Lambda and JSR 292 method handle

[Osvaldo Doederlein]

2009/12/17 Rémi Forax <forax at univ-mlv.fr>

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


Terrence described some tricks, like encoding numeric data in Strings
because these can go in the constant pool. And I suppose that core libraries
can do even more evil things with access to Unsafe. But I'm wishing for
solutions, not hacks :)

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

[can = can't?] This is not a problem (IMHO) if we make it clear which things
are part of the language and which are implementation detail. See this bug I
describe here:
http://www.javalobby.org/java/forums/m92074023.html#92072670
The developer can always shoot himself in the foot by relying on
undocumented implementation detail. For closures, as I suggested before we
could make a best-effort to forbid bad things statically; for one thing we
can emit warnings of potential portability issues for any reflection over
closures.

Of course, it's much better if we can at least decide on the important
typing/linking/RRBC issues to use MethodHandle, even if, due to the short
time, we have a initial implementation that's sub-optimal with method
handling wrapping over bulky classes - if the latter are opaque, then that's
something that can be optimized incrementally in maintenance releases.

A+
Osvaldo