Re[2]: [Gc] Callbacks for GC events.

[Ivan Maidanski]

Hi!

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?

Regards.

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
> 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 accidentally 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 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
> 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 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
> signature.asc_______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/