Re: SCM_DEBUG_FREELIST

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 22 Jun 2000, Michael Livshin wrote:

> what is supposed to happen on every call to newcell with
> GUILE_DEBUG_FREELIST defined is this:
> 
> 0) free list is checked for any suspicious entries.
> 1) full GC is performed.
> 2) [implicit] at the end of the GC sweep phase the freelist check is
>    performed again.

The check 2) should be avoided, if possible, right?

> the actual situation is worse, because after the GC changes (freelist
> clustering, namely), the checks are not very useful -- the pre-GC
> check only scans one cluster (at most), and the post-GC check doesn't
> scan anything at all.  (my local tree has the fixes, but I'm sitting
> on it for now, for various uninteresting reasons).

Do you plan to commit the fixes in the near future?  I then would wait
with my change until you are done with it.

> yes.  it should be used to detect unsufficient GC protection in user
> programs (the C-written ones).

I see.  However, I wonder if this is very helpful then:  It can be
difficult to find the point in the user code that actually dropped a
necessary reference.  We could probably do better if we added some
corresponding debugging code to the cell accessing macros SCM_CELL_WORD*
and friends.  This may be a little bit difficult, since those parts of the
code that legally deal with free-cells then must not use those macros (or 
do some weird #undef trickery).  However, this should be advantageous over
the current use:

* GUILE_DEBUG_FREELIST will only detect if there have been writes to
  the car element of cells that are in the freelist.  The earliest moment
  when this can be detected is when another fresh cell is ordered.

* If every cell access is checked, then not only write accesses to the 
  car of a free cell, but all read and write accesses to a free cell will
  cause a core dump in the very moment that access happens.

Whether it is a performance loss or improvement is difficult to decide,
since the current scheme does only cause overhead when a new cell is
ordered, but then it has to scan the whole freelist.  With the alternative
solution, we would perform checks with every cell access, but these checks
are far less expensive.  It's not clear to me yet, though, at which point
the gc should be triggered with the alternate scheme.  If this would be
done with every cell access, that would be expensive!  However, as with
the current solution there might be some additional run-time settable flag
that allows to switch that debugging on or off, thus allowing to reduce
the run-time penalty for parts of the code that are not of interest.

Best regards
Dirk