Re: guile/guile-core/libguile init.c

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> But, perhaps more importantly, this is a big step towards removing
> critical sections for pre-emptive multi-threading.  The new GC scheme
> maintains a master list consisting of clusters of cells.  Each thread
> has its own freelist which is refilled by calling scm_gc_newcell.
> scm_gc_newcell, in turn, fills the list by taking one cluster off the
> master list.

In the old GC scheme, a cell has three phases in its life: first it is
a free cell, then an allocated cell, and, thirdly, a real cell.  Each
phase requires at least one store to memory.  And, since we now have
multiple freelists, the free phase can actually be repeated, so
there's a waste of at least one (+ repeated free phases) store to
memory per cell used.

Also, the allocated phase is entered too late to work in pre-emptive
multithreading, because a thread might be interrupted just before
storing scm_tc16_allocated into a cell, and next thread might trigger
GC.

I now suggest the following change to be applied to the new GC scheme:

* Remove the scm_tc16_allocated phase.  If a cell isn't "real", it is
  scm_tc_free_cell.

* Mark the spines of the cluster lists in the mark phase of GC

* Don't collect free cells during the sweep, just let them stay in
  their freelist or in their cluster.

In a threaded Guile, each master list will be protected by a mutex, so
it is thread safe to manipulate a master list in an arbitrary way.

* Don't destroy the values in master->n_objects and
  master->clustertail at the end of each sweep.  Instead use these
  values at the beginning of the sweep to initialize nfreelist and
  n_objects, so that the sweep phase, instead of creating a new
  cluster list, will append to the existing cluster list.

And, voila, we have saved a lot of operations, *and* we have a
pre-emptive multi-threading safe GC scheme!  8-)