Profiling Garbage Collector

Sean Kelly sean at f4.ca
Thu Nov 29 08:20:48 PST 2007


Chad J wrote:
> As I contemplated the challenge of determining whether or not a library 
> (not an entire program) causes heap activity and whether or not it 
> leaves garbage for the gc, I decided that having a profiling garbage 
> collector would be really useful for such tasks.
> 
> Such a profiling collector would have the following features:
> - For each type in the program, it would track how many times each type 
> is allocated, how many times each type is manually deleted, and how many 
> times each type is collected by the garbage collector.
> - It can return a string containing the above information.  Also, it'd 
> be nice if the gc could summarize by saying which types were "leaked" 
> most frequently.
> - Ideally, it not only uses type information but also has some help from 
> the compiler.  Thus it not only knows about types, but can keep track of 
> every single allocation on a file by file, line by line, basis.  That 
> way finding leaks would be as simple as reading "the allocation of Foo 
> at line 42 in file bar.d was collected 1762 times".  This may require 
> some extra origination information to be stored in each object/array/etc 
> for programs undergoing GC profiling.
> 
> Well, other than spouting the idea and refusing to implement it, I am 
> wondering - has anyone made this kind of thing yet?

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


More information about the Digitalmars-d-learn mailing list