From: Svein Ove Aas
Subject: Incremental garbage collectors
Date: 
Message-ID: <fETec.6315$px6.89346@news2.e.nsc.no>
I'm working on writing an incremental garbage collector for hopeful
inclusion in Movitz, although I'm currently using a simple (self-written)
virtual machine. I don't want to deal with the complexity of an actual x86
implementation before I need to, but I'm pretty sure it's close enough to
be useful.

The VM isn't actually done yet, though, unless you count design. That comes
later, as does the OS.


That said, I'm wondering if you have any links I might find useful about
garbage collectors. I'm up the creek without a paddle, and would appreciate
not having to reinvent *too* many wheels.

- Svein Ove Aas

From: Paul Dietz
Subject: Re: Incremental garbage collectors
Date: 
Message-ID: <407C2878.35CE9565@motorola.com>
Svein Ove Aas wrote:

> That said, I'm wondering if you have any links I might find useful about
> garbage collectors. I'm up the creek without a paddle, and would appreciate
> not having to reinvent *too* many wheels.

http://www.memorymanagement.org/
http://www.iecc.com/gclist/GC-faq.html
http://www.cs.kent.ac.uk/people/staff/rej/gc.html
ftp://ftp.cs.utexas.edu/pub/garbage
ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps

	Paul
From: Frode Vatvedt Fjeld
Subject: Re: Incremental garbage collectors
Date: 
Message-ID: <2hu0zn98pn.fsf@vserver.cs.uit.no>
Svein Ove Aas <·····@brage.info> writes:

> I'm working on writing an incremental garbage collector for hopeful
> inclusion in Movitz, although I'm currently using a simple
> (self-written) virtual machine. I don't want to deal with the
> complexity of an actual x86 implementation before I need to, but I'm
> pretty sure it's close enough to be useful.
>
> The VM isn't actually done yet, though, unless you count
> design. That comes later, as does the OS.

Any particular reason not to use Bochs? I find bochs very useful for
OS debugging purposes.

> That said, I'm wondering if you have any links I might find useful
> about garbage collectors. I'm up the creek without a paddle, and
> would appreciate not having to reinvent *too* many wheels.

The book "Garbage Collection" by Jones and Lins is an obvious
starting-point regarding GC in general.

And have you looked at movitz/losp/los0-gc.lisp from Movitz' CVS
archive, which is essentially a fully working GC implementation,
albeit not incremental? (Kind of interestingly, the GC in
los0-gc.lisp, while being very simple and naive, has a firm upper
bound on pause time, in the sub-millisecond range on recent hw.)

-- 
Frode Vatvedt Fjeld
From: Svein Ove Aas
Subject: Re: Incremental garbage collectors
Date: 
Message-ID: <lkUec.6320$px6.89551@news2.e.nsc.no>
Frode Vatvedt Fjeld wrote:

> Svein Ove Aas <·····@brage.info> writes:
> 
>> I'm working on writing an incremental garbage collector for hopeful
>> inclusion in Movitz, although I'm currently using a simple
>> (self-written) virtual machine. I don't want to deal with the
>> complexity of an actual x86 implementation before I need to, but I'm
>> pretty sure it's close enough to be useful.
>>
>> The VM isn't actually done yet, though, unless you count
>> design. That comes later, as does the OS.
> 
> Any particular reason not to use Bochs? I find bochs very useful for
> OS debugging purposes.

None in particular, except that I started this before I even heard of
Movitz, and there doesn't seem to be much reason to switch now.
As a testbed for *algorithms*, Bochs leaves something to be desired.

>> That said, I'm wondering if you have any links I might find useful
>> about garbage collectors. I'm up the creek without a paddle, and
>> would appreciate not having to reinvent *too* many wheels.
> 
> The book "Garbage Collection" by Jones and Lins is an obvious
> starting-point regarding GC in general.
> 
> And have you looked at movitz/losp/los0-gc.lisp from Movitz' CVS
> archive, which is essentially a fully working GC implementation,
> albeit not incremental? (Kind of interestingly, the GC in
> los0-gc.lisp, while being very simple and naive, has a firm upper
> bound on pause time, in the sub-millisecond range on recent hw.)

Looking now.

Are you sure that it would still be sub-millisecond if the machine has 400MB
used?


On a sidenote, I was plannning to write something very like Movitz
eventually; needless to say, I was very relieved to see you've gotten ahead
of me.

- Svein Ove Aas
From: Frode Vatvedt Fjeld
Subject: Re: Incremental garbage collectors
Date: 
Message-ID: <2hptab9763.fsf@vserver.cs.uit.no>
Svein Ove Aas <·····@brage.info> writes:

> Are you sure that it would still be sub-millisecond if the machine
> has 400MB used?

Well, as I said, that GC architecture is simple and naive, so the
amount of live, dynamically allocated data is effectively limited to
256 KB. So I guess the answer is both yes and no :-) I was certainly
not trying to imply that some better GC architecture wouldn't be
useful.

-- 
Frode Vatvedt Fjeld
From: Dave Roberts
Subject: Re: Incremental garbage collectors
Date: 
Message-ID: <XHrfc.41078$wP1.190949@attbi_s54>
Svein Ove Aas wrote:

> That said, I'm wondering if you have any links I might find useful about
> garbage collectors. I'm up the creek without a paddle, and would
> appreciate not having to reinvent *too* many wheels.

http://www.cs.utexas.edu/users/oops/papers.html
ftp://ftp.cs.utexas.edu/pub/garbage/

Particularly:
ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps


-- 
Dave Roberts
·············@re-move.droberts.com
From: Dave Roberts
Subject: Re: Incremental garbage collectors
Date: 
Message-ID: <PJrfc.43644$rg5.86045@attbi_s52>
Dave Roberts wrote:

> Svein Ove Aas wrote:
> 
>> That said, I'm wondering if you have any links I might find useful about
>> garbage collectors. I'm up the creek without a paddle, and would
>> appreciate not having to reinvent *too* many wheels.
> 
> http://www.cs.utexas.edu/users/oops/papers.html
> ftp://ftp.cs.utexas.edu/pub/garbage/
> 
> Particularly:
> ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps

Also, see:
http://www.cs.utexas.edu/users/oops/ 

-- 
Dave Roberts
·············@re-move.droberts.com