Heap profiling, of sorts

[Boehm, Hans]

> -----Original Message-----
> From: Thomas Aeby [mailto:aeby@graeff.com]
> ...
> 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).
It should be fairly easy to add a callback to the GC which allows
the client to generate a string representing the object type.
I'll see if I can add that.  The libgcj code to extract the class name
appears to be pretty trivial.

On X86/Linux, the current object descriptions are ugly but usually informative
even without a debugger.  I currently fork addr2line processes to get symbolic
addresses in the stack trace.  This is of course also slow.  In the long run,
there should be a way to use libgcj's mechanisms instead.
> 
> > 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.
It would be possible to build the debug version and to dynamically turn
off much of the debugging.  But you can't quite back to the performance
of the current version, so I'm not sure if this is worth pushing.  The
overhead that's hard to get rid of is:

1) An indirect call or test in the allocation path.  (The test is probably
cheaper.)

2) Probably an extra function call.

3) GC_debug_malloc and friends currently take different parameters,
in that the source file and line number are explicitly passed.  This is very
useful for the standalone GC, and almost completely useless for libgcj.  It
should be possible to avoid this for libgcj-like clients.

Perhaps the best way to handle this in the long run is to try to duplicate
the frequently called allocation code in each dso, and then make the decision
about debugging in that small layer, with a common libgcj.so.  That would
also avoid the frequent cross-dso allocation calls.  But I don't know whether that's
possible with the current linker.

Hans
> 
> 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
>