RE: gcj: mem leaks & speed.

[Andrew Haley <aph at redhat dot com>]

Boehm, Hans writes:
 > > 
 > > In the previous example, perhaps we should recognize and remove dead
 > > allocations just because it will give us better benchmark numbers :-).
 > > For all I know tree-ssa will do this magically without special effort
 > > from us.  But note that we can only do it in limited cases; e.g., if
 > > the benchmark allocated any class other than itself, we couldn't
 > > optimize due to binary compatibility constraints.
 > > 
 > Doesn't it make more sense to aim for escape analysis and stack allocation?

Yes, but escape analysis plays badly with binary compatibility and
inheritance.  For example, it's quite legal to replace a class in
which an object does not escape with a subclass in which it does.

 > That's actually useful.  And once you do that, you should be able
 > to discover that the resulting stack locations are all dead for the
 > contrived benchmarks, and thus remove the rest of the allocation
 > overhead.

That's true, because benchmarks are self-contained and so you really
can do that analysis.  But large scale applications aren't always so
self-contained.

Andrew.