Re[2]: [Gc] Question on avoiding data races (and compatibility with Mono)

Ivan Maidanski ivmai at
Fri Sep 11 11:35:21 PDT 2009


"Boehm, Hans" <hans.boehm at> wrote:
> I'd probably add a GC_get_heap_size_inner() which doesn't lock, and is called by GC_get_heap_size().  They should both be externally visible.  If Mono is the only client for the former, I might not even document it in gc.h.

A good idea except that:
- not only GC_get_heap_size_inner() but also the friends (at least for GC_get_free_bytes);
- I think it would be good to export them properly (GC_API+GC_CALL) in some public header (not gc.h but, say, gc_mark.h which contains several such functions).

If no objections, I'll prepare the patch (in several days).

> I'm happy to make minor changes like this to support something like Mono, if it minimizes divergence of GC versions.
> Hans
> > Hi!
> > 
> > It turns out that GC_get_heap_size() and friends are 
> > synchronized now (at least for half a year) but as I recall 
> > some projects (eg., Mono) with a modified libgc call them 
> > while holding the lock (from a proprietary callback during 
> > garbage collection or, even, with stopped world) - should we 
> > leave all as-is (letting them solve their problems - I dont 
> > see quick solution for it since it's impossible to 
> > temporarily unlock before calling that callbacks) or add 
> > unsynchronized GC_get_...() equivalents?

More information about the Gc mailing list