rhine-ml icon indicating copy to clipboard operation
rhine-ml copied to clipboard

Is there any design documentation/memory layout etc?

Open simon-brooke opened this issue 9 years ago • 2 comments

Specifically, do you envisage your stack as a fixed-size vector as Clojure, or as a linked list in heap space as in most other Lisp implementations? Do you intend to separate heapspace from cons space, and if so will vectors of cons-space float in the heap? Do you envisage a reference counting or a mark-and-sweep garbage collector?

Cheers!

simon-brooke avatar Feb 17 '15 23:02 simon-brooke

Some of these questions are still open, because we have to figure out how to garbage collect using the gc.statepoint mechanism in LLVM; that requires gc'able (malloc'ed) pointer to be in "address space 1", and other (alloca'ed) pointers to be in addrspace(0). The separation isn't as clean now, and a test related to let and closure is currently failing. In short, memory layout is a bit of a TODO still.

Vectors are manually manged contiguous blocks of memory returned by malloc (or gc_malloc once we have a working gc). They are NOT linked lists.

I eventually see us building a generational gc, but mark-and-sweep will be a step along the way.

Feel free to contribute documentation that might be a little rough around the edges.

artagnon avatar Feb 18 '15 14:02 artagnon

I have to confess I haven't actually got Rhine to build yet, but I am looking for a clojure-like Lisp which runs on bare hardware. I've written some essays on memory management for clojure-like Lisps here: http://blog.journeyman.cc/search/label/Memory%20management which might be interesting. I have a lot of other projects on at present so may not be able to contribute much quickly, but I am interested and will at least follow what you're up to!

On 18 February 2015 at 14:13, Ramkumar Ramachandra <[email protected]

wrote:

Some of these questions are still open, because we have to figure out how to garbage collect using the gc.statepoint mechanism in LLVM; that requires gc'able (malloc'ed) pointer to be in "address space 1", and other (alloca'ed) pointers to be in addrspace(0). The separation isn't as clean now, and a test related to let and closure is currently failing. In short, memory layout is a bit of a TODO still.

Vectors are manually manged contiguous blocks of memory returned by malloc (or gc_malloc once we have a working gc). They are NOT linked lists.

I eventually see us building a generational gc, but mark-and-sweep will be a step along the way.

Feel free to contribute documentation that might be a little rough around the edges.

— Reply to this email directly or view it on GitHub https://github.com/artagnon/rhine/issues/20#issuecomment-74869456.

Simon Brooke :: http://www.journeyman.cc/~simon/

    ;; Stultus in monte

simon-brooke avatar Feb 18 '15 18:02 simon-brooke