Hi, Neil Jerram <[EMAIL PROTECTED]> writes:
> Fascinating! Assuming we can resolve the details you have listed, > what are the other high-level pros/cons, apart from performance? Does > this mean we would discard all Guile's own GC code? Also, is Boehm GC > as sophisticated as the generational GC ideas that people have talked > over the last year about adding Guile, or can we expect future Boehm > GC development to cover this? As Han-Wen said, BGC is generational. More details are available from: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html For Guile, the main advantage is maintainability: using BGC significantly reduces code complexity (i.e., it removes the hardest-to-read parts of the code, it disentangles GC code from functional code), it may improve portability, and it has the potential to improve performance --- although that potential hasn't shown up yet. ;-) >From a technical viewpoint, it is much, much easier to use, and avoids many common programming errors: unless otherwise specified, every register and every piece of memory is scanned for pointers, not only the heap (however, only heap regions allocated via the GC allocation routines are scanned). Also, it periodically clears the unused part of the stack, which may help avoid certain leaks (as the eval-stack leak described in [0]). Thanks, Ludovic. [0] http://lists.gnu.org/archive/html/guile-devel/2005-11/msg00047.html _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
