Re: [Gc] Callbacks for GC events.
ivmai at mail.ru
Tue Nov 9 22:28:50 PST 2010
1. The suitable header file for the declarations of this sort is gc_mark.h.
2. GC_callback_... variables shouldn't be exported (on the contrary, define them as STATIC) - define & declare setters and getters (see GC_set_start_callback for the sample).
3. GC_try_to_collect, GC_gcollect[_and_unmap]: why did you put GC_callback_start/stop_collect instead of GC_try_to_collect_general?
Wed, 10 Nov 2010 16:03:11 +1100 Paul Bone <pbone at csse.unimelb.edu.au>:
> 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
> > included many such callbacks, for several reasons:
> > 1) It's hard to define what they mean. The notion of a collection
> > and ending is very different in incremental mode, for example.
> > 2) It's tricky to specify exactly what you can do in which callback.
> > thread stopping/starting callbacks are an excellent example. You're
> > 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
> > 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
> doing so is safe and I've seen at least one crash when accidentally doing
> 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 aren'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
> > 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
> > intended to be called every time any GC work is done? What about the
> > phase, which is almost always done incrementally, even in stop-the-world
> > mode? Or do these apply only to world-stopped intervals? Or each
> > 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
> any incremental work.
> > b) We declare them in a separate header file, with disclaimers stating
> > the APIs are not likely to remain stable indefinitely, and you probably
> > to somewhat understand GC internals to make sense out of them. And there
> > weird and platform-dependent restrictions on what may be done in a
> > It may take extreme effort to reliably avoid deadlocks and the like.
> I've listed the two restrictions I'm familiar 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.
> ATTACHMENT: application/pgp-signature
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc