[Gc] Callbacks for GC events.

Paul Bone pbone at csse.unimelb.edu.au
Tue Nov 9 21:03:11 PST 2010


On Wed, Nov 10, 2010 at 03:13:54AM +0000, 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.

Understandably.

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

In any of these you may not allocate nor free any memory using the GC.  I doubt
doing so is safe and I've seen at least one crash when accidently doing this.

In the start/stop world, you may not use locks, but you may use your CPUs
atomic operations, I do exactly this to protect some resources.

These really arn't new restrictions, they're the sort of things that a
programmer must never do from a signal handler.

> I doubt that we would ever be able to reasonably document such an API and
> keep it stable.

Do you mean that function's signatures may be unstable or the documentation may
be unstable (such as the semantics of the function).

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

For my purposes, 'collection mode' is any work that the collector has to do
that doesn't directly support allocation.  It covers marking and sweeping and
any incremental work.

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

I've listed the two restrictions I'm farmiliar with above.

Also We should document that the thread paused, and thread resumed callbacks
don't work on Darwin.  I don't know how to make them work.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20101110/0ba66d18/attachment.pgp


More information about the Gc mailing list