Re: [Gc] GC_get_bytes_since_gc locks
ivmai at mail.ru
Wed Aug 24 06:05:08 PDT 2011
But what should we do?
A. Make the getter unsynchronized again (after 2 years of being synchronized) but this would break some clients expecting no race (or expecting nothing since they are not aware of a potential race here);
B. Make the getter (and the other ones) lock-free but then every access inside BDWGC should be changed to use AO store/getter primitives (thus resulting in worse compiler optimization);
C. Add _inner lock-free getter (to be use only from the GC call-backs).
Probably, there's a 4th alternative to change the logic of your app to make it independent of whether the getter is synchronized or not.
24 08 2011, 11:52 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>:
> On Wed, Aug 24, 2011 at 1:21 AM, Boehm, Hans <hans.boehm at hp.com> wrote:
> > Is it possible to work around the problem by calling
> > GC_get_bytes_since_gc_inner() if it exists, and GC_get_bytes_since_gc() if
> > it doesn’t?
> It can be done, but this requires more autoconf magic and hardcoding library
> behavior. It also has the problem that GC_get_bytes_since_gc_inner() does
> not exist right now, neither in 7.1 nor in any of the 7.2alpha versions.
> There autoconf will detect that _inner does not exist and use the wrong
> I am very much tempted to use GC_bytes_allocd, but gc_priv.h does not work
> unless it is included with the same compilation flags and C preprocessor
> definitions that BDWGC used -- and since these do not survive installation,
> the variable is useless for external users.
> My guess is that very few people (hopefully only one) are affected by this.
> > Changing it back would I think make the interface less consistent, and
> > probably make the most common usages of GC_get_bytes_since_gc() less likely
> > to be correct.
> I presume that all high level languages using some statistics of garbage
> collection will rely on this function. AFAIK there is no other reliable,
> backwards compatible, non-wrapping way to determine the amount of memory
> allocated by the library than inspecting this value among collections.
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
More information about the Gc