New

[Osvaldo Doederlein]

2010/3/29 Howard Lovatt <howard.lovatt at gmail.com>

> This is a two way argument, you could equally say can you demonstrate that
> the *compiler* can optimize my point 4 correctly. I am not suggesting that
> the JVM must optimize the creation away, just that it optionally can. If you
> are clear were the object is potentially created then the programmer can
> always do the optimization (just like the programmer already does for normal
> objects and is reminded to do so by the new keyword).
>

In practice, there is a strong direction of javac to not perform any
optimizations at all (except IIRC, minimal dead-code removal based on
constants so we have some level of conditional compilation). And my
estimation of chances to change this direction are a rounding error above
zero. Not to mention that relying on javac for advanced optimizations opens
other can of worms if you consider the larger toolchain - e.g. the Eclipse
Compiler project is still fixing Java5 bugs...

A+
Osvaldo


> On 29 March 2010 22:46, Osvaldo Doederlein <opinali at gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>
>
> --
>  -- Howard.
>