gcj: mem leaks & speed.

Wed Feb 4 18:58:00 GMT 2004

That's a good point.
A lot of this seems to depend on whether gcc will eventually support some
sort of "whole program" optimization, which doesn't have to worry about binary
compatibility rules. It seems to me that there are a lot of optimizations
commonly performed by JVMs that you can't do without that. And I think there
are a reasonable number of applications for which I'm willing to trade off
better performance for more recompilations of user code. 
Hans
> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com]
> Sent: Wednesday, February 04, 2004 4:33 AM
> To: Boehm, Hans
> Cc: 'tromey@redhat.com'; Hans Boehm; Rutger Ovidius; java@gcc.gnu.org
> Subject: RE: gcj: mem leaks & speed.
>>> 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.
>