Limitations of conservative GC

[Jim Blandy <jimb@red-bean.com>]

Perry asked:
> Is not being able to relocate memory/perform modern garbage
> collection/handle reentrancy/etc. really worth the simplicity the
> conservative GC provides?

That's not the tradeoff we have.  You can have incremental,
generational, multithreaded conservative GC.  Guile's GC isn't any
harder to make thread-friendly than any other GC; they're just all
bitchin' hard.

Conservative GC prohibits you from copying some objects.  But there
are lots of ways to work around that limitation.  For example, there's
no intrinsic connection between copying GC's and generational GC's.
And you can have "mostly-copying" collectors (if you think Compaq is
not going to sue you for violating the patent they inherited from
DEC).

Conservative GC imposes one other burden: at the moment, you can't use
Guile in a multithreaded program even if you guarantee (with locks or
whatever) that only one thread will invoke a Guile function at a time.
That's pretty weird; most libraries will let you do that.  But this
restriction arises because Guile wants to know where all the stacks
are.  That's unusual.

However, this requirement is probably easy to meet, using some
knowledge of the underlying thread system.  This difficulty is minor
compared with the other problems involved in multithreaded GC.