This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Tom> While they live on the stack, the only references to these objects are > Tom> rooted in $continuation and $environment and follow their respective > Tom> chains. The general collector can regard references from the stack to > Tom> the heap as GC roots -- but there's no reason it can't trace those > Tom> incrementally. > How do you deal with the fact that $continuation changes very > frequently? Here's (in my ind) the obvious way to approach this: The > GC is tracing some old value of $continuation. When it's finished, > there's a new one there, with new frames hanging off it. So the > tracer needs to go back to the new value. Is there a guarantee this > process will finish if the steps have bounded size? Right. There's a bunch of little cases like that in here where you have to relate the rates of various things going on in order to guarantee termination of GC phases. Frankly, I approach hacking Pika with a kind of iterative deepening of the design space: I'm personally convinced I can solve that subproblem but I can't, off the top of my head, demonstrate the solution. As a general rule, by the time it becomes necessary to blacken $continuation or $environment in order to close out a trace phase, make sure that only shallow work is needed. -t