|A handful of LISP questions email@example.com (tactics) (2007-06-19)|
|Re: A handful of LISP questions firstname.lastname@example.org (Gene) (2007-06-19)|
|Re: A handful of LISP questions email@example.com (Nils M Holm) (2007-06-19)|
|Re: A handful of LISP questions firstname.lastname@example.org (Martin Rodgers) (2007-06-19)|
|Re: A handful of LISP questions email@example.com (Lieven Marchand) (2007-06-19)|
|Re: A handful of LISP questions firstname.lastname@example.org (Andreas Hinze) (2007-06-19)|
|Re: A handful of LISP questions email@example.com (tactics) (2007-06-20)|
|Re: A handful of LISP questions firstname.lastname@example.org (Gene) (2007-06-20)|
|Date:||Wed, 20 Jun 2007 06:47:39 -0700|
|Posted-Date:||20 Jun 2007 20:38:30 EDT|
> Let me rephrase. When garbage collecting with Mark and Sweep, you
> need a root set of objects.
Indeed! With any kind of garbage collection.
> This is the set of objects in immediate view of
> the program.
The collection of objects that might be accessed by the program at
some time in the future form a (usually disconnected) graph with
objects as nodes and pointers as edges. The root set is some set of
pointers from which each node in the graph can be reached.
> For example, the objects on the call stack or in the
> current environment.
> I guess from what people have told me on this
> list is that you call the collector at the start of the eval function
> when memory exceeds a threshold. Then, in that case, do I just flag
> everything in the current environment as being part of the root set?
Where you must look for roots depends on your implementation and
environment. It can be tricky and indeed it can depend on where you
call the collector. To your list you'll have to add implementation
language variables that may hold pointers. This is likely to include
processor registers. Depending on how you define success, just
calling gc at the start of eval has a certain lack of appeal. You can
always invent scenarios where the lisp must abort because memory is
exhausted, when a gc would allow the program to continue. Therefore
you'd like a design where gc can be called inside the allocator "just
in time" to prevent an ugly death.
Return to the
Search the comp.compilers archives again.