Stack overflow in the garbage collector

[DemiMarie]

When running julia --lisp (so using Julia's version of Femtolisp) with this Scheme file:

(define (longer-and-longer x)
  (let ((my-car (car x)))
    (set-car! x (cons my-car #f))
    (longer-and-longer x)))

(longer-and-longer (cons #f #f))

the result is a SIGSEGV due to a stack overflow (confirmed by Valgrind).

I suspect this is in the garbage collector, since replacing car with cdr (and set-car! with set-cdr! takes much longer before segfaulting (possibly due to a use-after-free error, most likely due to integer overflow).

[briandamgaard]

It's obvious why the stack overflow occurs. The Cheeney-style copying garbage collectors I've seen in Bezanson's projects have always suffered from the foolish bug that the relocate() function calls itself recursively when it relocates the car part of a lisp pair, and also when it relocates the final cdr part of the lisp pair at the end of a list.

This has always been an unfortunate blemish on all the otherwise very elegant and intelligent code he so graciously has published over the years.

static value_t relocate(value_t v)
...
car_(nc) = relocate(a);
...
*pcdr = (d==NIL) ? NIL : relocate(d);

[JeffBezanson]

projects have always
over the years

How many projects are we talking about here?

[briandamgaard]

Jeff wrote:

How many projects are we talking about here?

The main FemtoLisp project and all its so-called tiny variants, e.g., "lisp.c" and "lisp2.c"

[JeffBezanson]

Ok, so one project.

[JeffBezanson]

I would be happy to see a pull request fixing this. I do think there are trade-offs though --- we would need to use more heap space, and it might be slower, and car-deep structures are pretty rare in real code. Of course it could be a build-time option if necessary.

[briandamgaard]

Jeff wrote:

we would need to use more heap space, and it might be slower,

1. It does not need more heap space.
2. It does not run slower.

Your GC code aspires to be is a simple copying collector, which is a perfectly fine choice, in particular for the tiny variants. You have just misunderstood how such a simple copying GC works, so you have conflated copying and reference-updating.

A correct implementation is at least as simple and elegant as what you have, and it won't even take an hour's work to rewrite your code.

For convenience, here is a link: https://en.wikipedia.org/wiki/Cheney's_algorithm

Please note that this is not a different algorithm. This is what your code always has aspired to implement: A simple copying garbage collector. Your existing code just suffers from a misunderstanding about how it's done.

[JeffBezanson]

It seems to me the difference is breadth-first vs. depth-first order. Yes, I see breadth-first order might be better.

[briandamgaard]

Jeff wrote:

It seems to me the difference is breadth-first vs. depth-first order.
Yes, I see breadth-first order might be better.

It's not just a question about being better, it's a question about being correct. When it's done the right way, there is no recursion. Put differently, there is no drain on stack space, so stack overflow is not an issue.

The "might" in your sentence indicates that you haven't fully understood the crucial difference yet. When you've had the time to let it sink in, I'm sure you'll realize how easy and quickly you can fix it, both for the benefit of the users, but also for the algorithmic beauty, which is one of the rewards for the (us) programmers. Your projects are so good that they surely deserve a correctly implemented and elegant garbage collector!

[nilern]

Indeed I assumed that Cheney's algorithm would be used as it is very much compatible with the "simple, interesting & fast" philosophy of Femtolisp. I was going to just implement it myself and make a PR but then I realized that

1. It actually isn't a small change. Femtolisp does not have uniform heap object headers like e.g. Chicken, instead using tagged pointers also for heap object type tags. But the Cheney scan pointer is not a tagged pointer so the algorithm would not have access to the layout information for the current object.
2. Adding the required object headers would actually use more heap space.
3. Breadth-first copying in itself might actually be faster (no stack!), but on the other hand it spreads list conses around while depth-first copying colocates them, so overall cache utilization would be worse.

[briandamgaard]

Nilern wrote:

It actually isn't a small change. Femtolisp does not have uniform heap
object headers like e.g. Chicken, instead using tagged pointers
also for heap object type tags.

Ah, the missing object headers is indeed a nuisance, but from the top of my head, I'd say that it's still doable in an easy manner. All it takes is, that you ensure that all objects on the heap are 8-byte aligned. That buys you the needed extra tag-value to signal that an object in the old heap contains a forward pointer after it has been relocated.

nilern wrote:

Breadth-first copying in itself might actually be faster (no stack!),
but on the other hand it spreads list conses around while
depth-first copying colocates them, so overall cache utilization would be worse.

FemtoLisp is a small and elegant Lisp. It's cannot be - and is not meant to be - particularly efficient, so this is an unimportant detail.

[briandamgaard]

Brian wrote:

All it takes is, that you ensure that all objects on the heap are 8-byte aligned.
That buys you the needed extra tag-value to signal that an object in the old
heap contains a forward pointer after it has been relocated.

I have only looked at the very small FemtoLisp versions (I cannot remember if there is a larger one, more geared toward production mode), and here it's not even necessary with an extra tag-value for a forward pointer. The only objects on the heap are cons cells.

This means that an untagged pointer (as if it has the tag "TAG_NUM") can be used to signal that an object in the old heap contains a forward pointer. A pleasant side effect is, that it makes the handling of the forward pointers as efficient as it possibly can be.

[nilern]

Breadth-first copying in itself might actually be faster (no stack!),
but on the other hand it spreads list conses around while
depth-first copying colocates them, so overall cache utilization would be worse.

FemtoLisp is a small and elegant Lisp. It's cannot be - and is not meant to be - particularly efficient, so this is an unimportant detail.

It's not particularly inefficient either. Just thought to mention that the breadth-first algorithm is not strictly superior.

I have only looked at the very small FemtoLisp versions (I cannot remember if there is a larger one, more geared toward production mode), and here it's not even necessary with an extra tag-value for a forward pointer. The only objects on the heap are cons cells.

Indeed there is a main production version and it has vectors and C interop values and whatnot.

This means that an untagged pointer (as if it has the tag "TAG_NUM") can be used to signal that an object in the old heap contains a forward pointer. A pleasant side effect is, that it makes the handling of the forward pointers as efficient as it possibly can be.

Forwarding pointers are already implemented more or less like that. The problem is finding the start of the next object in the tospace queue. If there were just cons cells we could just bump a value_t pointer by two. When there are many types their sizes have to be stored on the heap in some uniform manner and the start of an object has to be distinguishable from alignment holes if some objects are more than word-aligned.

Of course there is also the Big Bag of Pages arrangement (i.e. group the objects by type so headers are not needed) but I really don't think we want to go there.

[briandamgaard]

nilern wrote:

The problem is finding the start of the next object in the tospace queue.
If there were just cons cells we could just bump a value_t pointer by two.
When there are many types their sizes have to be stored on the heap
in some uniform manner and the start of an object has to be distinguishable
from alignment holes if some objects are more than word-aligned.

It's not a problem to find the the start of the next object, and you don't need to store object sizes for all objects types.

It's easy and efficient to use a lookup table indexed by object type, reserving the return value "length = 0" to represent "variable length object type".

All variable sized objects on the heap contain their length, or they contain enough information to compute the length on the fly, including alignment.

Strictly speaking, the length information stored in variable sized objects don't need to have their lengths stored in a uniform manner. Uniformity is more a matter of convenience for the programmer.

[nilern]

It's easy and efficient to use a lookup table indexed by object type, reserving the return value "length = 0" to represent "variable length object type".
All variable sized objects on the heap contain their length, or they contain enough information to compute the length on the fly, including alignment.

Yes, if we have the type at hand. But the Cheney scan pointer cannot be a tagged pointer, so we don't have the tag bits of the current object, so there is nothing to index with; the type is unknown.

Also if there are uninitialized alignment holes we can't get the alignment of the next object because we don't know where it starts so we can't hop over the hole to its start to get the alignment...

Strictly speaking, the length information stored in variable sized objects don't need to have their lengths stored in a uniform manner. Uniformity is more a matter of convenience for the programmer.

"Uniform" was a poor choice of words. What I meant is that the heap contains enough "reflection" information for the GC to traverse it in order of addresses instead of following pointers. The specific term is "heap parsability". Actual uniformity does also have some performance advantage but I don't know how significant that is, especially in this context.