Re: removing scm_gc_mark_conservatively()

[Dirk Herrmann]

On 25 Sep 2001, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > On 22 Sep 2001, Marius Vollmer wrote:
> > 
> > > [...]
> > > I'm not sure whether we have such code, but we might.
> >
> > [...] In the above code, the correct solution would be to use
> > scm_remember_upto_here_1(x) after the call to the gc.
> 
> Yes, the code that I've shown is broken and needs to be fixed,
> ultimately.  I was talking about our current situation, were
> conservative scanning of `free' cells is no longer done, but the
> broken code has not been fixed.
> 
> Are you sure that no such broken use of SCM_NEWCELL exists in Guile
> and in user code?  If that would be so, great!

I am not sure.  However, at least I can tell you the following:  I
usually compile guile with SCM_DEBUG=1, which also enables the exhaustive
cell checking.  Once I have executed the test suite with
  (set-debug-cell-accesses! 1)
which means that after (or before, I am not sure at the moment) every cell
access an additional garbage collection is called.  This, btw, slows guile
down by a very large factor - it even takes some minutes for (exit) to
execute.  A lot of initialization errors are caught this way, but I
have never executed it since, as it really takes a lot of time.  I can't
say that the erroneous code that you have shown would be detected - this
also requires that the compiler will definitely throw away unused values
as soon as they are no longer used.  However, I remember that I did find
some initialization errors at that time.  (As the testsuite is not very
exhaustive, the set of functions that have been tested that way is far
from complete.)

> As the real solution, I have proposed removing SCM_NEWCELL completely,
> and only provide means (a function or a macro) for simultaneously
> allocating and initializing a new cell.  In the deprecation period,

In principle, yes, this would be nice.  And it will work in at least 90%
of the cases.  However, as stated in the above mentioned thread, there are
some places where this initialization scheme will not work nicely, because
the a priory computation of the initialization values can't be done
without some hassle.

> allocating and initializing a new cell.  In the deprecation period,
> SCM_NEWCELL would be made safe by having it set the type slot to
> scm_tc16_allocated.  Please see the "Let's throw out SCM_NEWCELL"
> thread.

Just for clarification:  The scm_tc16_allocated cells would then be
conservatively scanned during gc, right?

Best regards
Dirk Herrmann