The gc change (Was: Making Guile slower)

[Greg Harvey <Greg dot Harvey at thezone dot net>]

(This is probably screwing with mail readers threading, since I only
replied to Jost instead of following up... I also edited the mail
slightly, so I'm probably confusing Jost as well ;)

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> 
> -----------------------------------------------------------------------
>  This is very common in guile (though this is not the case that can go
>  wrong; any kind of allocation after the newcell is sufficient). Now,
>  look at gc.c; see what the gc does when it finds a freecell (and this
>  is what the gc should do). See if you can guess what happens to the
>  object if that scm_must_malloc triggers a gc. If you were to say "hey,
>  that cell can be put on the freelist, even though I'm just about to
>  use it! I'll be screwed when a call to NEWCELL gets back that cell"
>  you'd be right, and that's exactly why it was changed. If you feel up
>  to going through all the guile code and all the c code that uses guile
>  and changing it so that the order of allocation is safe, then feel
>  free to revert the patch.
> ----------------------------------------------------------------------
> 
> 
> Can you please put the reason for a change into the changelog?
> Just paste the above description into the change log and everyone
> is happy. :)

Oops; I had a better description (not so annoyed as that one (sorry
Marius, I just woke up a short time ago, so I'm still a bit grouchy
;')... however, we should also not start a performance witchhunt,
particularly against important bugfixes, without considering the
reasons behind a particular change), but Greg didn't include it when
he applied the patch. It didn't show up on bug guile because it
resulted from an email exchange about problems in scwm. 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.

-- 
Gregh