A syntax option (function types versus arrays)

[Howard Lovatt]

I probably didn't make myself clear. I was not saying that escape  
analysis was the exclusive means or the most appropriate means of  
optimizing lambdas. I was simply pointing out that the JVM can and  
does optimize object creation.

As to having the compiler do the optimization, this has proven to be  
troublsome because the compiler does not see the whole appplication  
(unlike the JVM). EG String caching and final field caching are full  
of gottchas. Therefore I think it is best left to the JVM.

I agree that there are few uses for lambda identity. However there are  
some and it would also be confusing to have special rules for lambdas.  
Special rules are the cause of trouble for Stings and static finals.  
Best make everything an object with consistent rules.

   -- Howard Lovatt +61 419 971 263 (sent from my PDA)

On 12/03/2010, at 6:40 PM, Peter Levart <peter.levart at marand.si> wrote:

> On 03/12/10, Howard Lovatt wrote:
>> My understanding is that the JVM is free to optimize object creation
>> away as long as it can convince itself that the effect cannot be
>> observed, hence the escape analysis proposed that will stack allocate
>> instead of heap allocate.
>
> Escape analysis won't be able to optimize such "constant" lambda  
> expressions in most cases where they should be optimized, since  
> lambdas are there to be passed to some code (i.e. they escape  
> compilation unit). On the other hand you usually won't need to  
> depend on reference identity of a lambda instance, so it's perfectly  
> understandable for specification to NOT specify it. Therefore "new"  
> keyword is misleading in this respect.
>
> Regards, Peter
>
>>
>> On 12 March 2010 10:22, Alex Blewitt <alex.blewitt at gmail.com> wrote:
>>> On 11 Mar 2010, at 23:14, John Nilsson wrote:
>>>
>>> On Thu, Mar 11, 2010 at 11:58 PM, Howard Lovatt <howard.lovatt at gmail.com 
>>> >
>>> wrote:
>>>>
>>>> There is an advantage in spelling out that you have an expensive
>>>> operation in that people are more likely to be aware of a potential
>>>> problem and hence avoid it in the first place
>>>
>>>
>>> But it is only expensive if you assume a broken compiler or VM.  
>>> There is
>>> nothing inherent in the language to suggest that it should be  
>>> expensive.
>>>
>>> If you specify 'new' then the runtime VM is forced to lay out  
>>> space for the
>>> new data as well as return a fresh instance:
>>> http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#41147
>>> Next, space is allocated for the new class instance. Every time the
>>> expression is evaluated, a fresh object is created
>>> So by using the keyword 'new' - and assuming unchanged semantics  
>>> in this
>>> area of the JLS - then you are going to at least cycle through the  
>>> new
>>> generation even if the runtime JIT may be able to optimise it away  
>>> in
>>> certain circumstances.
>>> However, if the keyword 'new'  is not used then these issues do  
>>> not apply.
>>> Alex
>>
>>
>>
>>