Re: gc and call/cc design space notes (DRAFT)

[Thomas Bushnell, BSG]

Miroslav Silovic <address@hidden> writes:

> To counter your cross-examination, are you sure that these bugs are
> conservativism-related? Also, were they unbounded leaks or just a few
> elements left over in the table (which would NOT be a GC bug, since GC
> is not *supposed* to guarantee prompt cleanups)?

Here's one case that was noticed not too long ago in which
conservative GC fails systematically.

On a Sparc, stack frames are generally bigger than get actually filled
(there can be lots of extra stack slots not touched by the program).
Such slots will sit there, perhaps holding uncleared references to
dead data, and the gc will incorrectly think the referenced data is
live.

There turn out to be natural patterns of code in which the data
referenced grows without bound and can never be noticed; people have
indeed seen this occur in real-world (not contrived) Sparc programs
using conservative GC.

Thomas