A syntax option (function types versus arrays)
Peter Levart
peter.levart at marand.si
Thu Mar 11 23:40:49 PST 2010
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
>
>
>
>
More information about the lambda-dev
mailing list