Profiling Garbage Collector

[Kris]

There was a conversation about this just the other week, for Tango. It's on 
the cards, with some really slick features :)


"Chad J" <gamerChad at _spamIsBad_gmail.com> wrote in message 
news:fil6a2$2nu0$1 at digitalmars.com...
> 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?