Hi, Guile currently uses the Boehm-Demers-Weiser collector with "Java-style finalization", which is to say that finalizers are unordered. This is good in the sense that Guile's GC can collect cycles of objects with finalizers that point to each other. It also has some understudied disadvantages or strange behavior.
One disadvantage is that with the default topological finalization order of BDW-GC, cycles of objects with finalizers are uncollectable. I think that BDW-GC will warn to the console when this is the case, in the default mode, so perhaps it's not that bad. Another disadvantage is that running the finalizer of object O1 which links to finalizable object O2 could see O2 after O2's finalizer has been run, because finalizers are unordered. This is almost certainly not what you would expect. Also, if O1 has a mark function, you could mark O1 when O1 is on the finalization queue but not yet finalized, and O2 has already been finalized -- so your mark functions also need to be ready to deal with unordered finalization. Keep in mind that in Guile 2.x, finalizers are uncommon. They are probably more common in user code than in Guile code, in the form of SMOB free functions. This is especially the case in code ported from earlier Guile versions. Useful links: Finalization http://hboehm.info/gc/finalization.html Finalizers, Threads, and the Java Memory Model http://hboehm.info/misc_slides/java_finalizers.pdf Foreign Object Memory Management http://www.gnu.org/software/guile/docs/master/guile.html/Foreign-Object-Memory-Management.html#Foreign-Object-Memory-Management Open question: should Guile configure the BDW GC in a different way? Topological finalization is desirable for all the reasons Boehm links in that first article. Should it allow the user to configure it? I believe it is currently unordered due to issues with guardians, but I don't recall correctly. Thoughts? Andy -- http://wingolog.org/
