Re: [Gc] GC_get_bytes_since_gc locks
ivmai at mail.ru
Thu Aug 25 12:25:14 PDT 2011
24 08 2011, 18:35 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>:
> On Wed, Aug 24, 2011 at 3:05 PM, Ivan Maidanski <ivmai at mail.ru> wrote:
> > But what should we do?
> > Three variants:
> > 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);
> Which means they are broken and were already broken back in the past or the
> documentation was not clear.
No, neither, consider a client which calls that function not from a GC callback - it is not broken now and it hadn't been broken before provided it were launched on a single-core CPU arch that has AO_load equal to ordinary volatile read.
I agree that documentation was (and seems is) unclear.
I can guess why this method was not originally synchronized - because the collector was single-threaded.
> A'. Revert to original status and state in the header that those functions
> are not data safe and set the burden on the users. You have already made
> this choice for other functions.
Now I think that you are right. Probably we won't have many clients that use some 7.2alpha which would be broken (or potentially unstable) if we revert this back. (Probably, it would be good to send a letter of poll.)
We, of course, should create a safe variants for these functions (plus for GC_get_gc_no).
The functions under the scope:
- GC_get_heap_size (has inner variant, is not a single read),
- GC_get_free_bytes (has inner variant, is not a single read),
- GC_get_unmapped_bytes (new function),
- GC_get_total_bytes (is not a single read),
What action should be best for each of these? (Also, not to mention, Hans should agree these arguable changes too.)
> Regarding the two years age of the locking change, I am not sure this figure
> is relevant. This synchronization feature lives only in 7.2alpha tarballs
> and in the CVS repository. Are we to consider them as references? When I
> last checked, Debian, FreeBSD, OpenBSD relied on 7.1 or 7.0 or even earlier
> versions. ECL has been shipping 7.1 for a long time due to the lack of
> stable releases and only now because of the OS X Lion problems did I have to
> work with the unstable sources.
I haven't seen a non-alpha release for ages. And it looks to me the next would be another alpha unless we create a branch for stabilization - I mean grab commits from master that are considered to be bug-fixes (we also probably have to set some timeout for this stabilization).
> 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).
> C is inconsistent due to some functions being locked and some not. It makes
> it also unpredictable for the user to know which and why. It makes software
> backwards incompatible now and also if you decide in later versions to
> switch some other functions from non-locking to locking.
> D. (Which I mentioned in my previous email and compatible with A') Make
> functions _lock() or _safe() that lock explicitly, thus warning the user.
> 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.
> This is not possible, as I explained in my previous email. The only reason
> why I need this getter is because I need to gather statistics about
> allocated bytes and this has to be done in the garbage collector hook before
> the counter is erased. The only way for this 4th alternative is simply to
> renounce to this function and do our own counter, with the performance loss
> this implies.
> I any case this is just my opinion, my 2c. I am really grateful for the
> existence of the BDWGC library and for the work both Hans Boehm and you have
> put on it. Without this huge effort software such as ECL would not exist at
> On the other hand I understand that academic rigor should be taken with a
> grain of salt. Simplicity and consistency is always preferable, given
> sufficient documentation and clear contracts.
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
More information about the Gc