[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: removing scm_gc_mark_conservatively()
From: |
Dirk Herrmann |
Subject: |
Re: removing scm_gc_mark_conservatively() |
Date: |
Wed, 26 Sep 2001 00:56:34 +0200 (MEST) |
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
- removing scm_gc_mark_conservatively(), Chris Cramer, 2001/09/16
- Re: removing scm_gc_mark_conservatively(), Dirk Herrmann, 2001/09/17
- Re: removing scm_gc_mark_conservatively(), Marius Vollmer, 2001/09/22
- Re: removing scm_gc_mark_conservatively(), Dirk Herrmann, 2001/09/24
- Re: removing scm_gc_mark_conservatively(), Marius Vollmer, 2001/09/25
- Re: removing scm_gc_mark_conservatively(),
Dirk Herrmann <=
- Re: removing scm_gc_mark_conservatively(), Marius Vollmer, 2001/09/26
- Re: removing scm_gc_mark_conservatively(), Dirk Herrmann, 2001/09/27
- Re: removing scm_gc_mark_conservatively(), Dirk Herrmann, 2001/09/27
- Re: removing scm_gc_mark_conservatively(), Marius Vollmer, 2001/09/27
- Re: removing scm_gc_mark_conservatively(), Marius Vollmer, 2001/09/27