This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: guile/guile-core/libguile init.c
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-)