New

[Osvaldo Doederlein]

I have an idea to settle this debate and avoid further fight: a design that
depends on advanced optimization (either EA or some new one) should only be
considered as soon as we have, at least in alpha stage, said optimization in
the JDK7 project. And by "we have it" I imply that we also have specific
benchmarks that shows that the optimization does indeed eliminate the cost
it should. So, I'm not content with a microbenchmarks of non-lambda code
(e.g. en enhanced-for loop of collections that needs scalar replacement of
Iterator objects); I want to see benchmarks that show a well-representative
assorting of lambda code, demonstrating that the optimizer will typically
eliminate extra allocation imposed by the 'new'.

[EA & stack allocation is already available; and we don't need a working
prototype of a compiler for the lambda proposal as it's possible to manually
write the same desugared code that would be emitted by such compiler. So,
whoever believes in the lemma "let's make a mess - the JIT will clean up
after us") must only write some benchmark code.]

P.S.: EA & stack allocation are coming back in JDK 6u20, which is now in
beta and is planned to ship on June. It seems that EA is in enough good
shape as they're enabling it by default. OTOH, it's still exclusive to
HotSpot Server, and I have little hope that the Client compiler will get
this optimization any time soon. So I reinforce my negative vote (FWIW) on
any important language design that will be good only for server-side apps -
lambdas is a proposal for the next JavaSE platform, not for the next JavaEE
platform.

A+
Osvaldo

2010/3/29 Peter Levart <peter.levart at marand.si>

> On 03/29/10, Howard Lovatt wrote:
> > Just a note. I wouldn't suggest escape analysis as the appropriate
> > optimization. It would need to be a new optimization.
> >
>
> Do you have any idea how such optimization should work?
>
> Regards, Peter
>
>