guile-devel
[Top][All Lists]
Advanced

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

Re: gc issues


From: Michael Livshin
Subject: Re: gc issues
Date: 16 Sep 2000 16:29:11 +0300
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

Dirk Herrmann <address@hidden> writes:

> My current assumption was, that every thread has a set of free
> cells,

yes.

> which it can obtain even during a gc.

hmmm.  my assumption was different here.  it probably could be
arranged, though, now that I think about it...

> Only to refill this thread-private pool of cells a lock would be
> needed.  A gc running in a different thread would treat all of those free
> cells reserved for running threads as being in use.  Thus, the need for
> locking would be minimized.
> 
> This does not work if memory coherency is not guaranteed:  We may find
> that (while a gc is running) a different thread obtains a cell from its
> private pool.  Then, the reference to this cell is removed from the
> private pool, but it may be that the corresponding reference on the stack
> does not become visible in time.  To guarantee that these things are
> synchronized, a lock would be needed anyway.

oooh, oooh, I have an idea!

* what I plan to do anyway (for lazy sweep) is this: the "cluster"
  concept of the current GC (a cluster is a chunk of the freelist)
  will be eliminated.  instead, the allocator will hand out memory in
  pre-swept cards.  so the "private pool" of a thread will be defined
  as "all the free cells in the active card", and a card is just a
  continuous chunk of memory at a known address.

* so all we have to do is just scan the "active" cards conservatively.
  voila, no locking needed!

> Yes, and as it seems, threading on multiprocessors forces us to use locks
> for cell initialization anyway (except I am missing something).  But, on
> the other hand, if we have to use a lock in order to obtain every single
> cell, would we still need a thread-private freelist at all?

yes.  you may need interlocking between mutators and the GC, but
there's no reason to require interlocking between mutators themselves
-- you'll just serialize all allocation this way.

> > Who's afraid of the garbage collector?
> 
> I am, and I have always been.  Now you know it.  I feel better now :-)

I should talk to the sigmonster, it seems. ;)

-- 
All ITS machines now have hardware for a new machine instruction --
BFM
Be Fruitful and Multiply.
Please update your programs.



reply via email to

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