[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the new gc asserts in master

From: Han-Wen Nienhuys
Subject: Re: the new gc asserts in master
Date: Tue, 26 Aug 2008 23:12:09 -0300
User-agent: Thunderbird (X11/20080723)

Andy Wingo escreveu:
> Hi,
> I just merged master to guile-vm, but I'm not sure if I really wanted to
> do that now. Normal test suites are failing:
>     lt-guile: gc.c:604: scm_i_gc: Assertion `scm_cells_allocated == 
> scm_i_marked_count ()' failed.
>     /home/wingo/src/guile/vm/test-suite/standalone/test-use-srfi: line 27: 
> 29507 Aborted                 guile -q --use-srfi=1,10 > /dev/null  <<EOF
>     (if (and (defined? 'partition)
>              (defined? 'define-reader-ctor))
>         (exit 0)   ;; good
>         (exit 1))  ;; bad
>     EOF
>     guile --use-srfi=1,10 fails to run
>     FAIL: test-use-srfi
> This is on a core 2 duo, in 32-bit mode, configured as:
>     CFLAGS="-g -O2" ./configure --with-threads --enable-maintainer-mode 
> --prefix=/opt/guile-vm
> So it seems that the new gc "cleanups" don't want you to touch mark bits
> outside the mark phase. This is incompatible with other uses inside
> guile itself, e.g. the SCM_DEBUG_CELL_ACCESSES == 1 case in inline.h, or

I am pushing a fix for this to master.

> even the lazy smob case I wrote about here:

I would classify the use of mark bits outside of the mark phase as outside
of the defined API.  If you want to have weak pointer semantics, use
a weak hashtable, or implement reference counting on the C side.

I am actuallly inclined to add add abort() for anyone who calls scm_gc_mark() 
outside the marking phase.

> There are more cases, rgrep for SCM_SET_GC_MARK in libguile/*.[ch].

I looked through all of these, and these all happen during the mark phase.

> I'm going to commit an #if 0 around those asserts in the vm branch,
> because I don't have the brain power to deal with it. (It is irritating
> that I have to even write this mail.) Certainly if the near-term choice
> is between inaccurate statistics and calls to abort(), I know which
> choice I prefer...

The statistics form the basis of the allocation strategy, so they are not 
a 'cute' feature.  If these statistics go off, we overallocate, or spend too 
much time trying garbage collect when there is nothing to reclaim.

 Han-Wen Nienhuys - address@hidden -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]