5 ms·
The Scheme-79 chip (https://dspace.mit.edu/handle/1721.1/6334 https://dspace.mit.edu/handle/1721.1/6334) was doing GC in microcode. According to Steel & Sussman
by oecumena 4y ago
The Scheme-79 chip (https://dspace.mit.edu/handle/1721.1/6334 https://dspace.mit.edu/handle/1721.1/6334) was doing GC in microcode. According to Steel & Sussman it typically spent 80% of time collecting. :-) RMS invented "phantom stacks" to reduce the amount of garbage due to closures, not sure this was ever implemented anywhere.
- gumby 4y agoI forgot about that chip. yeah, I don’t think anyone looked at the phantom stack idea. Perhaps interlisp should have.
- kragen 4y agoGenerational 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?
- fanf2 4y agoThat 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 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”
- kragen 4y agoWell, I know, but I think he turned out to be wrong in that case. Fast enough, maybe.
- gumby 4y agoIt'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).
- kragen 4y agoYeah, whatever Appel thinks, the stack is always faster. But sometimes the heap penalty is affordable. Before generational GC it was ridiculous.