Heap profiling, of sorts

Fri Mar 12 11:02:00 GMT 2004

On Fri, 2004年03月12日 at 00:57, Boehm, Hans wrote:
> This is an initial pass at a patch to make heap backtraces, as they were
> already supported by the collector, work with gcj. 

That's just GREAT! :-)
I'll try this out against my gcj compiled app once I get some time I can
spend on debugging memory issues, again.
> Generally this gives you a good idea of why things in the heap are live. I find
> it more useful than a breakdown of the heap composition by type, though that would
> clearly be useful, too. 

With backtracing info being collected by GC one can always write a small
native procedure dumping the whole heap if necessary ... well, of course
it would be nice if such a procedure would already make part of libgcj
ready for invocation by Java programs :-)
> (And getting Java types into the backtraces would perhaps
> be even nicer.)

Indeed, since I'm afraid Java programmers are not very used to
interprete hex pointer addresses, themselves. And due to the in-memory
structure it's very easy to find the class of an object even if you
prefer to stay in C (each object starts with a pointer to the vtable
containing a pointer to the class object containing a pointer to a
string containig its name - it's just a question of deciding which
objects actually *are* Java objects and which aren't).
> does mean that you need a separate build for heap debugging, which is very
> unfortunate. (Fixing this seems to be hard without adding to the allocation path.)

Well, it's not extremely important - it's already real fun to get some
memory allocation debugging at all (which is - indeed - a problem with
pretty every Java runtime environment).
I haven't understand yet, however, why it's not possible to write a
GC_malloc() routine that just decides at program startup if it should
do the additional debugging stuff or not (or if this suits better
a GC_debug_malloc() that just passes requests through to GC_malloc()
if requested so) ... but then I haven't really looked at the code,
so take this as a naive comment.
Best regards,
Tom
----------------------------------------------------------------------------
Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26
4180040
Internet: aeby@graeff.com PGP public key
available
----------------------------------------------------------------------------
Programmers never die - they just branch to a new address