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

[Paolo Molaro]

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.

> A profiler for Mono 1.2 is unlikely to be useful for 2.0 (Or whenever we
> get a moving gc). Even if the api were designed so that the profiler
> were correct, the things one wants to look at in each impl are very
> different.

In this case we are talking about something that is common for any GC:
the list of objects that survived a GC. Getting a callback for each
live object is the right interface for this and you can build on that.

> I'd also like to get boehm specific stuff (eg, number of blocks
> blacklisted). Maybe these functions need to be put somewhere else...

This is something completely unrelated, which can be implemented in other
ways, like generalized counters: they don't belong in the profiling
interface. I'll add some code maybe next week for it: I need to check
if what I have can be also used to implement the PerformanceCounters stuff
in System or corlib.

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

> > enum {
> > 	/* maybe also add suspend and resume events */
> > 	MONO_GC_EVENT_START,
> > 	MONO_GC_EVENT_RECLAIM,
> > 	MONO_GC_EVENT_END
> > };
> > 
> > typedef void (*MonoProfileGCFunc)         (MonoProfiler *prof, int event_type, int gen_num);
> > 
> > Of course for the current GC the generation number will be always 0, but
> > the interface will work with the new GC. Note also that the generation number
> > is not needed, since you can easily keep your counter when the MONO_GC_EVENT_START
> > event is received.
> 
> So MONO_GC_EVENT_RECLAIM would be like the one that allows me to see the
> mark bits?

It will be the event when you'll be able to request a heap walk to the GC,
with a callback for each object.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better