guile-devel
[Top][All Lists]
Advanced

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

gc issues


From: Dirk Herrmann
Subject: gc issues
Date: Wed, 13 Sep 2000 10:03:52 +0200 (MEST)

Hello together.

I'd like to point out two gc issues:

First
-----

With regards to multiple threads running, free cells should be
conservatively scanned.  If we look at object initialization, it is done
(or should be) as follows:

- get a new cell
- initialize everything but the cell's type entry
- finally, initialize the cell's type entry

With multiple threads, where one might be running a gc, it is essential,
that the type entry is initialized last, because if guile's gc finds a
type entry, then it assumes that all cell entries are correctly
initialized.  In other words, if the type entry was initialized, but the
rest of the cell holds some bogus data, then guile will crash during gc.

However, even if this pattern was followed throughout guile, there would
still be the chance, that references get lost:

SCM make_foo_from_bar (SCM bar)
{
  SCM foo;

  SCM_NEWCELL (foo);
  SCM_SET_CELL_OBJECT_1 (foo, bar);     /* 1 */
  SCM_SET_CELL_TYPE (foo, scm_tc_foo);  /* 2 */
}

>From the compilers point of view, there is no need to keep bar in a local
variable or register beyond the line marked '1'.  In the example above
this is unlikely, since there is not much code executed between lines 1
and 2.  But even in that example:  Assume that the compiler has, in order
to execute line 2, to fetch scm_tc_foo from memory into a register.  It
may then use the register which previously held bar.  If a thread switch
occurs immediately after that, there is no reference any more to bar on
the stack.  However, there _is_ a reference to bar within the new cell,
but this can only be found if free cells are scanned conservatively.


Second
------

The recent changes to the garbage collector made the use of a
scm_tc_allocated type tag unnecessary.  However, this means, that if
some code obtains a fresh cell, the type tag of this cell will still be 
scm_tc_free_cell.

So far, everything is great.  But, this breaks the way the
SCM_DEBUG_CELL_ACCESSES debug mode works.  When enabled, this mode checks
every cell access (read or write), whether a free cell is accessed.  The
purpose is to detect erroneously freed cells (because for whatever reason
the reference was temporarily lost and the gc freed the cell).

There are some options how this can be fixed:

- get rid of that debugging mode at all.
- only check read accesses (this will probably work, because the first
  thing that is done with a new cell is to overwrite its contents _and_
  cell type with something that makes sense.)
- re-introduce some scm_tc_allocated tag, but use it only when debugging.

Maybe there are other/better solutions.


Best regards
Dirk



reply via email to

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