New

[Howard Lovatt]

Comments in line

On 29 March 2010 21:22, Peter Levart <peter.levart at marand.si> wrote:

>  On 03/29/10, Mark Thornton wrote:
>
> > Howard Lovatt wrote:
>
> > > 3. The main argument for not using new is that the compiler can 'lift'
> the
>
> > > lambda to be static if it doesn't access any instance fields or local
>
> > > variables. However this type of optimization has a poor history in
> Java,
>
> > > think String interning and copying of static fields.
>
> I never had any trouble as a consequence of interned Strings.
>

Java Puzzlers 13 & 62 are to do with interned Strings, so I would have
thought it does occur. I have corrected programs that have used == when they
should have used equals (they passed the unit tests because of interning).
This group has also commented on the undesirability of Integer interning for
some values and not others.


> What do you mean by "copying of static fields"?
>

Java Puzzlers 93 is about this one


>  > > In Java a JVM
>
> > > optimization has proven much more successful than a compiler
> optimization.
>
> > > Hence using new, which would allow a JVM optimization but prevent a
> compiler
>
> > > optimization, is the best choice.
>
> > >
>
> > On the other hand the JVM optimisations (escape analysis) to reduce heap
>
> > allocation have been "coming soon" for more years than I care to
> remember.
>
> >
>
> But it has arrived, hasn't it? It's in JDK 1.6.0_14 (check -
> XX:+DoEscapeAnalysis)...
>
> The thing to note is that such escape analysis is only effective if it can
> positively determine that an object instance (constructed with new) can not
> escape local computation. If someone wanted to use escape analysis to
> optimize instantiation of lambdas then such analysis could only be effective
> if the instantiation of lambda and invocation of it was peformed as part of
> the same local computation. For example (in term's of Lowatt's syntax):
>
> {
>
> #<int()> lambda = new #<int()>(42);
>
> assert 42 == lambda.();
>
> }
>
> I think that such usages are useless (why creating a lambda in order to
> only invoke it afterwards).
>
> Other usages involve passing lambda instance to some method. In those cases
> escape analysis can't help if those methods are not aggresively inlined. I
> think that relying on such situations would render optimization in case of
> lambdas practically non-effective.
>
> I think that specifying lambda identity by not specifying it is so far the
> most promissing direction to enable optimizations. This unfortunately
> conflicts with "new" semantics but I don't find this as a drawback for
> specifying a usefull syntax that doesn't include "new".
>
> Regards, Peter
>
>
Just a note. I wouldn't suggest escape analysis as the appropriate
optimization. It would need to be a new optimization.


-- 
 -- Howard.