News for hackers. Stuff that matters.
Re:Treadmill garbage collector by H. Baker by gumby on Tuesday July 26, 2022 @12:47AM (#32234343)
I forgot about that chip.

yeah, I don’t think anyone looked at the phantom stack idea. Perhaps interlisp should have.

Re:Treadmill garbage collector by H. Baker by kragen on Tuesday July 26, 2022 @09:25AM (#32237950)
Generational GC might make heap-allocating your activation records a viable option, even if you're not satisfied with CPython levels of performance. I mean in a sense that's what Chicken does, right?
Re:Treadmill garbage collector by H. Baker by fanf2 on Tuesday July 26, 2022 @10:42AM (#32238968)
That is the argument made by Andrew Appel’s paper “garbage collection can be faster than stack allocation” https://www.cs.princeton.edu/~appel/papers/45.pdf and it’s the compilation strategy used by SML/NJ as set out in Appel’s book “compiling with continuations”
Re:Treadmill garbage collector by H. Baker by kragen on Tuesday July 26, 2022 @01:57PM (#32241528)
Well, I know, but I think he turned out to be wrong in that case. Fast enough, maybe.
Re:Treadmill garbage collector by H. Baker by gumby on Tuesday July 26, 2022 @05:33PM (#32244358)
It's pretty hard to beat the pushj/popj approach, except that you have to lock out the GC before returning (as it may be scanning the activation records to find roots).
Re:Treadmill garbage collector by H. Baker by kragen on Tuesday July 26, 2022 @08:23PM (#32245643)
Yeah, whatever Appel thinks, the stack is always faster. But sometimes the heap penalty is affordable. Before generational GC it was ridiculous.