Re[2]: [Gc] GC_get_bytes_since_gc locks

Ivan Maidanski ivmai at
Tue Aug 23 11:59:13 PDT 2011

Hi Juan and Hans,

In "git log" a search for this function gives:

    2009-06-11  Hans Boehm <Hans.Boehm at> (Really Ivan Maidanski)
            * misc.c (GC_get_heap_size, GC_get_free_bytes,
            GC_get_bytes_since_gc, GC_get_total_bytes): Acquire the GC lock to
            avoid data races.

In gmane, search for "GC_get_bytes_since_gc race" gives:

   "Boehm, Hans" <hans.boehm at ...> wrote:
   > Good point.  They should acquire the GC lock.  We should conform to the C++0x rules whenever possible.   That
   means we should avoid data races whenever possible.

I remember that I've added some _inner functions (declared in gc_mark.h - GC_get_heap_size and GC_get_free_bytes - probably not the right header file for such functions).

The general contract for these _inner functions - they should be called from a client function invoked by GC_call_with_alloc_lock.
All functions in gc.h (unless stated the opposite) are free to acquire the lock.

As for GC_get_bytes_since_gc, it is up to implementation whether it does a single read or not - but, according to the contract it should give a consistent result.

Juan -

Please redesign your patch taking into account this information (look for GC_get_heap_size_inner declaration and implementation as a guidance).

PS. Should we add _inner versions for some or all of the rest of the getters? 


23 08 2011, 22:41 "Boehm, Hans" <hans.boehm at>:
> In general, yes, it is necessary.  See for example my HotPar 2011 paper: .
> It probably makes sense to introduce a second version that's callable from contexts in which the lock is already held, i.e. GC_get_bytes_since_gc_inner(), which would hopefully also solve your problem.
> Hans
> From: gc-bounces at [mailto:gc-bounces at] On Behalf Of Juan Jose Garcia-Ripoll
> Sent: Tuesday, August 23, 2011 5:28 AM
> To: gc at
> Subject: [Gc] GC_get_bytes_since_gc locks
> Formerly this function was very simple could be called from a routine that marks or that perform some task before or after garbage collection (one of the hooks). Now this is not the case. A useless lock has been inserted in a function that all it does is read a C variable. Really, is this necessary?
> GC_API size_t GC_CALL GC_get_bytes_since_gc(void)
> {
>     size_t value;
>     LOCK();
>     value = GC_bytes_allocd;
>     UNLOCK();
>     return value;
> }
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)

More information about the Gc mailing list