[Mono-devel-list] [PATCH] GC Profiling Interfaces

Ben Maurer bmaurer at ximian.com
Sun Jan 23 14:28:34 EST 2005


On Sun, 2005-01-23 at 19:03 +0100, Paolo Molaro wrote:
> On 01/23/05 Ben Maurer wrote:
> > This interface is not designed to be useful for a different gc impl. It
> > doesn't handle moving objects *at all*.
> 
> That's what I said: the interface is misdesigned.
> > > As for knowing that an object died vs knowing which objects are alive, it's
> > > a simple difference which you could do when post processing, too, if needed.
> > > Either way, we may consider exporting such an ugly interface only if
> > > the overhead with the heap walk is significant.
> > 
> > Maybe, considering dependency on the gc impl, we should consider this a
> > private contract with the gc profiler? 
> 
> Maybe, considering that implementing and switching to a moving
> and generational GC in a few months will be hard already, we should not
> introduce new interfaces that won't work when we can implement an
> interface that does. I'm not concerned about the code in your profiler here,
> I know it will never work as is with a moving GC: the issue is the API
> interface. The heap walk is something that can be supported, your hackish
> function can't.

I've attached a patch that does everything other than making this heap
walk based.

I would really rather use a hackish interface that I know is non-buggy
right now than to spend a few days working on a generalized heap walk
that will probably require the brave souls who are using my code to fix
up Beagle, etc, to spend time with weird corner cases that pop up. I am
fine with the condition that a change in the GC will break my code.

-- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono.patch
Type: text/x-patch
Size: 10800 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050123/ca9dc1a3/attachment.bin 


More information about the Mono-devel-list mailing list