[Gc] Callbacks for GC events.

Paolo Molaro lupus at debian.org
Thu Nov 11 01:25:06 PST 2010

On 11/10/10 Boehm, Hans wrote:
> I have mixed feelings about this sort of thing.  In the past we've
> not included many such callbacks, for several reasons:
> 1) It's hard to define what they mean.  The notion of a collection
> beginning and ending is very different in incremental mode, for example.
> 2) It's tricky to specify exactly what you can do in which callback.
> The thread stopping/starting callbacks are an excellent example.
> You're trying to run code when the world is partially stopped.  If this
> code tries to acquire a low-level (e.g. libc) lock that's held by an
> already-stopped thread, I suspect the whole thing deadlocks.  And I
> suspect it's really hard to tell when such a lock might need to be
> acquired.  On some systems it probably happens when a function in a
> dynamic library is called the first time.

All good points. Some of these are part of the reasons we didn't push the mono
changes upstream. Some things for us are easier, since we don't support
incrememntal collection, but likely not suitable as a general API.
Some of the restrictions in the callbacks are a fact of life: a
profiler, for example, needs to be able to look at a stable version of
the heap and doing it when the world is stopped is likely the only way
to get that (just taking the GC lock doesn't prevent thread local
allocations from happening, for example).

On the API design, I suggest a single callback with an event_type
argument, instead of a different callback per event.

On the same topic, a function to walk the heap and get a callback
for each allocated pointer is also very useful (extra bonus if it also
can report references to other objects).


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

More information about the Gc mailing list