Re: BDW-GC branch updated

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> My main concern is/was that by moving to a conservatice GC, and
> _consequently changing the API of libguile to assume a conservative GC_
> (as outlined in [2]), you get third code relying on that as well. This
> would make it effectively impossible to ever switch back to a precise GC
> without potentially breaking all third-party code using the libguile
> API.

The current GC is "semi-conservative" in that it scans the C stack and
the "cell heap" for pointers, but nothing beyond that.  The current API
is built around this assumption.

BDW-GC is conservative: it scans everything, unless it's told otherwise
(e.g., `GC_malloc_atomic ()').  So you're right, the BDW-GC branch does
introduce API changes to take advantage of this, the most important of
which being that `scm_gc_malloc ()' memory is scanned and automatically
managed.

It's true that going back to the current "semi-precise" GC API would be
hard once we've made that change.

However, using a fully conservative GC makes it much easier to interact
with C, which is one of Guile's main goals as an extension language.

Furthermore, the concern about the risk of excess data retention caused
by conservative scanning holds as well for the current semi-conservative
GC.

Thus I believe the advantages of a conservative GC for Guile outweighs
its presumed disadvantages.

Thanks,
Ludo'.