gcj: mem leaks & speed.
Andrew Haley
aph@redhat.com
Wed Feb 4 12:34:00 GMT 2004
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.
More information about the Java
mailing list