gcj: mem leaks & speed.

Mon Feb 2 20:44:00 GMT 2004

>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> - The allocation sequence is still very suboptimal. We should
Hans> be generating calls directly into the GC in most cases.
We could do this pretty easily. I'll file a PR for this later.
Hans> And the allocation routine should perhaps be cloned in each
Hans> dynamic library.
Which allocation routine do you mean?
Hans> - We're currently still scanning way too many roots, though I
Hans> think that's being worked on.
Yeah, I'd like to change the default here as part of the overall "new
ABI", and require explicit marking. Hopefully this will be a 3.5
feature.
Hans> And as far as I can tell, the trend in JVMs is toward allowing
Hans> object pinning anyway. It's otherwise to hard to pass a Java
Hans> array to some native numerical library or the like.
Yeah. A JNI implementation could avoid pinning by handing you a copy
of an array. But this is hardly efficient if you're using very large
arrays.
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.
Tom