[Gc] Callbacks for GC events.
hans.boehm at hp.com
Tue Nov 9 19:13:54 PST 2010
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.
I doubt that we would ever be able to reasonably document such an API and keep it stable.
On the other hand, you point out a fairly important case in which it appears useful.
I'm OK with including them, if:
a) We try to document what they are intended to do a bit more carefully. What should it mean to start and stop an incremental collection? Are they intended to be called every time any GC work is done? What about the sweep phase, which is almost always done incrementally, even in stop-the-world mode? Or do these apply only to world-stopped intervals? Or each complete GC?
b) We declare them in a separate header file, with disclaimers stating that the APIs are not likely to remain stable indefinitely, and you probably need to somewhat understand GC internals to make sense out of them. And there are weird and platform-dependent restrictions on what may be done in a callback. It may take extreme effort to reliably avoid deadlocks and the like.
From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com] On Behalf Of Paul Bone
Sent: Sunday, November 07, 2010 7:47 PM
To: gc at linux.hpl.hp.com
Subject: [Gc] Callbacks for GC events.
I've written a patch against BoehmGC (attached) that introduces callbacks that the GC calls for certain events. I'm interested in the following events:
+ Collection begins
+ Collection ends
+ This thread is stopping (because the world is stopping).
+ This thread is resuming (because the world is resuming).
I use this for profiling the execution of multicore programs, these events along with events from Mercury's runtime can be used to generate a visualisation of a program's execution. The visualisation is rendered can be be explored with the ThreadScope tool.
I have two questions:
1. Can somebody please commit this into BoehmGC's CVS repository so that it
can be maintained by people who know the garbage collector better than I
2. Have I correctly instrumented the collector? I understand that my patch
only supports the pthread method of stopping the world, I'm okay with
that. However, I'm not confident that I've instrumented all the places
where the collector switches from allocation to collection mode and back
again. I've had to be careful not to make the collector send two 'start
collection' events in a row for example.
1. Mercury: https://www.mercury.csse.unimelb.edu.au
2. Threadscope: https://code.haskell.org/ThreadScope
More information about the Gc