RE: gcj: mem leaks & speed.

["Boehm, Hans" <hans_boehm at hp dot com>]

> Hans> And the allocation routine should perhaps be cloned in each
> Hans> dynamic library.
> 
> Which allocation routine do you mean?
The routines we should mostly be calling (and I think are eventually calling on Linux)
are GC_local_gcj_malloc and GC_local_malloc_atomic.  These should no doubt
also be using the new gcc tls support, which I think they're currently not.

The down side of doing this is that relatively minor GC changes potentially
invalidate existing dlls, so we should do this carefully.  But a dynamic library
call per allocation seems expensive on some architectures.

The collector could also export a version of these routines that relies on the
client to pass in a size class rather than a byte size.  Since the size is
often constant, that saves a comparison, usually untaken branch, addition, and shift,
again at the cost of turning some GC reconfigurations into ABI changes.
> 
> 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?
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.

Hans