Profiling Garbage Collector

Chad J gamerChad at _spamIsBad_gmail.com
Thu Nov 29 10:45:27 PST 2007


Sean Kelly wrote:
> 
> Tracking "leaked" objects is quite easy to do in Tango.  Check out 
> GC.collectHandler in tango.core.Memory.  There is currently no way to 
> track objects that were manually deleted, but it wouldn't be difficult 
> to add a similar hook for that.
> 
> 
> Sean

Yeah, when I thought of this I checked Tango and saw that.  I like that 
collect handler feature, a lot.  I don't think it pegs profiling though: 
even assuming I implement all of the logic and pass it to the tango GC, 
it still doesn't handle non-object entities, entities such as the 
ubiquitous array.

Well, you guys have probably discussed this already so feel free to 
ignore the below.  I feel like rambling.  I'm having fun with this :)

I also realized that even though the compiler might not be able to 
supply line and file info for an allocation, the library can still do a 
stack trace and discover the name of the function that caused the 
allocation.  This does, of course, assume debugging info that allows 
stack tracing - something that already exists.

So perhaps the GC/Tango needs these things to pull it off:
- An allocation handler.
- A collection handler.  (partially done)
- A deletion handler.
- A copying handler, if the GC wants to do copying.  This will be 
necessary to persist origination info.
- Maybe a reallocation handler, or maybe this can be thought of as a 
kind of allocation.
- All handlers must disclose the address(es) involved.
- All handlers must disclose full runtime type information.
- Each type (allocation/collection/deletion/copying) of handler must 
handle ANY kind of heap activity, not just objects.  Specialized 
handlers may be built on top of that.
- A stack trace function.  Preferably it lets you select which frames 
you want to see.

All of those are useful in general, but also just happen to be the right 
combination of stuff to implement a powerful gc profiler.  Now the 
profiler can be implemented in a separate module or somesuch.

The profiler can keep track of where each individual chunk of memory was 
allocated by means of an (associative?) array that maps addresses onto 
the function names that allocated them.  Then when a deletion/collection 
occurs, it can just look up the name of the function that caused the 
corresponding allocation.

I would love to even see just a stack trace function in Tango.  Even 
better if Exception calls it and dumps the thing to the console so I can 
know where I screwed up.


More information about the Digitalmars-d-learn mailing list