Re: The joy of garbage collection

"robbie.carlton@xxxxxxxxx" <robbie.carlton@xxxxxxxxx> writes:

> Thanks for the replies folks, there's definitely some things I can use
> in there. I'm implementing it in c, which I should have made clearer,
> so I can't rely on the native environment for garbage collection. And
> yes, one of the objectives is to get an understanding of garbage
> collection
>
>
> The gc papers look good, I've been looking for something like that, but
> there's a lot of extremely technical papers out there that assume much
> prior knowledge. It's good to have a place to start.
>
> Also, the free list is the part I was missing, and the various ideas
> for implementing that are interesting. I especially like the bitmap
> idea.
>
> "I don't see how they could be on the heap
> individually and unboxed, where would the mark bit go, how
> could sweep know to leave them?"
>
> Yes! This is what I still don't understand. Where do you put the
> unboxed data, as it can't go on the heap. I think I could now implement
> a very simple garbage collector if everything was boxed, but I'd like
> strings, arrays and various c data structures as unboxed data. Does
> this make sense?

The bitmap, or separate typecode, are not the fastest solutions. But
if you want to mix easily C with Lisp, they might be worthwhile.

A somewhat intermediate solution between boxed and separate typecode,
is to assign type to each page. You can have pages of int32, pages of
char, pages of float, etc. But for random C structures, you can only
use separate typecodes, and this means that you have to duplicate
about all processing.

Otherwise, for C values, you can use/reimplement a conservative GC
like BoehmGC.


>From the lisp side, I would keep all values boxed. C values can come
from a C heap, or C static data or C stack. But all C values can be
refered to with a pointer. So you can have a boxed and typed pointer
to refer to C values from the Lisp side. Do you need to GC C values?
I guess not. If you mean to use existing C libraries, they do their
own memory management.

(make-c-pointer c-type c-address) --> c-locative
(type-of c-locative) --> 'C-LOCATIVE
(type-of-c-value c-locative) --> c-type
(c-value c-locative) --> lisp-value
(c-value c-locative) is a place.

So you wouldn't need to manage unboxed C values in your lisp heap.


--
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
.

Relevant Pages

  • Re: The joy of garbage collection
    ... the underlying lisp takes care of it for you. ... array and store things in it appropriate to the imaginary ... All the things you put in it don't have pointers ... > storing unboxed data in the heap ...
    (comp.lang.lisp)
  • Re: List diagrams -- Siebel and Touretzky draw them differently
    ... Lisp heap which I just call a Lisp Object. ... So every word in memory is covered by a fixnum, ... In Allegro CL we call this punning "aligned pointers". ...
    (comp.lang.lisp)
  • Re: Problems with the On Lisp development model ...
    ... > goodness this is not the case for the bulk of the GCL heap. ... I don't know GCL, but most of the other Lisps are basically "heap" based ... I also think that systems like Allegro will allow you to load FASL files as, ... "read only" so that you can share them across multiple Lisp ...
    (comp.lang.lisp)
  • Re: wacky PPC lisp os fundamentals
    ... Just make proper conses that are two 64 bit cells ... Allen's Anatomy of Lisp. ... immediate not on the heap or a pair of immediates not on the heap. ... >> pointer indirection. ...
    (comp.lang.lisp)
  • Re: The joy of garbage collection
    ... so I can't rely on the native environment for garbage collection. ... there's a lot of extremely technical papers out there that assume much ... "I don't see how they could be on the heap ... arrays and various c data structures as unboxed data. ...
    (comp.lang.lisp)