Hacker News Reader

Garbage is always produced somewhere. It might be in variables which are no longer used before being freed, or in wasted space inside the allocator itself. What actually matters is (a) whether this performed better than GC'd Lisp equivalents of the era, and/or (b) if a GC Lisp is easier/faster/cheaper to write code for.

View on HN

Agreed that it's important not to overlook that allocator implementations often curiously resemble garbage collectors, although even keeping this in mind the act of eliminating what is usually referred to as "garbage collection" still turns out to be valuable since that garbage collector lives on top of the allocator already; having only one garbage collector in one's program can be advantageous to having two garbage collectors, one atop the other.

The OCaml GC uses huge long-lived blocks from the underlying allocator (malloc) so I don't think having two allocators is really a problem. Even less so on a LISP running on a LISP system where the LISP is the system allocator.

> wasted space inside the allocator itself

If you're only allocating fixed-size cons cells, you won't run into fragmentation issues.

You can still end up with fragmentation where you have one cell allocated in each page owned by the allocator. This mode of fragmentation is often quite problematic in practice.

Reply on news.ycombinator.com