Hi, Andreas Rottmann <a.rottm...@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'.
