Re: The gc change (Was: Making Guile slower)

[Jim Blandy <jimb at red-bean dot com>]

> This is what I put in the original changelog.
> 
> These changes are necessary to fix the case where you get a new cell,
> allocate some memory (which may cause a collection, this is the
> problem case), then put it in the cell. Current gc behaviour puts the
> freecell back on the freelist, which will end up totally hosing you;
> but we can't just mark free_cells, since it's most likely that a
> pointer to a free_cell is a conservative false positive (even if it is
> live, consider the must malloc case; we'd have to track down the whole
> rest of the freelist, and allocate a new heap segment to be really
> safe that that freecell is not part of a list we're building), so a
> new type is needed to represent the allocated, but not initialized
> type. This sequence is fairly common throughout guile (and code that
> uses guile), so it's pretty much a critical patch.


By the way, explanations of why a particular behavior is necessary
should go in the code, not in the ChangeLog.  If you find yourself
writing anything very long in the ChangeLog, you should stop and ask
yourself if it wouldn't be better as a comment.

Think from the point of view of someone staring at SCM_NEWCELL and
wondering why this apparently dead initialization is sitting in a
performance-critical piece of code.

An appropriate ChangeLog entry for this fix could be simply:

     (SCM_NEWCELL): Initialize cell type, to prevent it from being
     GC'd even if marked due to its type.

The reader will naturally look to the code to find the details.