Carp – A statically typed Lisp, without a GC, for real-time applications

Post by kragen » Sat, Oct 16, 2021, 1:21 AM UTC

kragen wrote: post #90

silon42 wrote: post #61

Earlier quoted context omitted.

It's really surprising that it's rare in functional languages. Immutability seems like it should guarantee no cycles (?), so reference counting could be used.

Reference counting is usually very expensive, because even reading a variable updates the reference count, and ending a scope involves testing the reference count of every variable defined inside the scope and conditionally deallocating the referent. Without reference counting, here's the end of a hairy function scope that deallocates 15 local variables and restores two callee-saved registers: 11a6: 48 83 c4 78 add $…

Post by xxs » Sat, Oct 16, 2021, 6:46 AM UTC

andi999 wrote: post #108

pjc50 wrote: post #63

Earlier quoted context omitted.

That's a question for the underlying allocator, surely? (Quite often the answer is "it isn't")

Not just for the allocator. I always thought a main point of a garbage collector was heap compactification (shuffling things around so there is more space), but maybe I am wrong.

Post by cmrdporcupine » Sat, Oct 16, 2021, 1:17 PM UTC

andi999 wrote: post #108

pjc50 wrote: post #63

Earlier quoted context omitted.

That's a question for the underlying allocator, surely? (Quite often the answer is "it isn't")

Not just for the allocator. I always thought a main point of a garbage collector was heap compactification (shuffling things around so there is more space), but maybe I am wrong.

Post by xxs » Sat, Oct 16, 2021, 3:14 PM UTC

andi999 wrote: post #126

cmrdporcupine wrote: post #125

Earlier quoted context omitted.

Nah, only copying / generational collectors do heap compactification. A simple Mark&Sweep collector doesn't, for example. Nor does reference counting. Both of which are used by many Lisp or Lisp-like languages. Nothing can substitute for a really good allocator.

So what happens to long running lisp programs? Running out of memory due to fragmentation eventually?

Post by p_l » Sun, Oct 17, 2021, 8:26 AM UTC

kragen wrote: post #120

p_l wrote: post #117

Earlier quoted context omitted.

This is more specifically about any reference counted system, though it also includes unique owner approaches and others. Namely, when you free an object, whether it involves manually written code to release anything it holds recursively, or through some form of reference counter, you do not know the size of object graph you're freeing . If you add any custom release logic to the mix (destructors, any kind of shutdow…

It's worth mentioning that (1) typically even ordinary reference counting avoids large pauses, because typically objects that go out of scope aren't the sole owners of a huge object graph, and that this is often but not always a significant improvement over (other simple kinds of) garbage collection; (2) there's a readily available tradeoff with reference counting known as "deferred decrement" which can meet hard rea…