[Top][All Lists]
[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.
- Re: gc issues, (continued)
- Re: gc issues, Carl R. Witty, 2000/09/13
- Re: gc issues, Michael Livshin, 2000/09/13
- Re: gc issues, Carl R. Witty, 2000/09/14
- Re: gc issues, Michael Livshin, 2000/09/14
- Re: gc issues, Jim Blandy, 2000/09/15
- Re: gc issues, Michael Livshin, 2000/09/13
- Re: gc issues, Michael Livshin, 2000/09/14
- Re: gc issues, Jim Blandy, 2000/09/14
- Re: gc issues, Michael Livshin, 2000/09/14
- Re: gc issues, Dirk Herrmann, 2000/09/14
- Re: gc issues,
Michael Livshin <=
- Re: gc issues, Dirk Herrmann, 2000/09/19
- Re: gc issues, Michael Livshin, 2000/09/19
- Re: gc issues, Mikael Djurfeldt, 2000/09/19
- Re: gc issues, Michael Livshin, 2000/09/19
- Re: gc issues, Mikael Djurfeldt, 2000/09/19
- Re: gc issues, Mikael Djurfeldt, 2000/09/19