l...@gnu.org (Ludovic Courtès) writes: > Andreas Rottmann <a.rottm...@gmx.at> writes: > >> Will going from a precise GC to BDW-GC not have drawbacks? IIRC, the PLT >> people went in the opposite direction. A quick google turned up this: >> >> http://www.cs.brown.edu/pipermail/plt-scheme/2006-June/013840.html >> >> I wonder if the reasons for switching to a precise GC listed in there >> will also apply to Guile. > > Thanks for the link! > > They write: > > There is one known problem, though, related to linked lists [Boehm, > POPL'02]. Unfortunately, we seem to hit this problem often in > practice, due to the way that threads and continuations are > implemented, and there doesn't seem to be a reliable way around it. > > The paper is "Bounding Space Usage of Conservative Garbage Collectors", > available from http://www.hpl.hp.com/personal/Hans_Boehm/gc/ . It > depicts scenarios where "false references" lead to unbounded data > retention. My interpretation of these scenarios and the "Summary" > section is that these cases are hopefully quite rare. > > Now, I don't have enough experience of long-running BDW-GC applications > to know whether it's a problem in practice. The PLT folks surely had > more experience (but with a different implementation IIUC). There are > also other schemes that use BDW-GC, such as Bigloo. > > However, it doesn't worry me as much as the current GC bugs (e.g., [0, 1]). > > Also, there are definite benefits to using a conservative GC for > libguile, given how tightly it can be integrated with C (e.g., [2]). > 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.
However, take that just as my < 2€-cent ;-). Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
