Bob La Quey wrote:
The stack is saved in the environment. Doesn't that let you get back to
where you were?
No, the stack pointer is saved in the environment, not the stack.
Therefore, setjmp/longjmp only let you unwind the stack, not wind it
forward.
Now, you can write non-portable assembly to save/restore the stack, but
you are effectively creating a threading system. You might as well
create a separate thread and bounce messages off of it.
One of the big papers in Lisp is about how to use setjmp/longjmp for
continuation passing trampolines but minimize the performance impact.
Effectively, the solution is to make normal continuation calls which
leave lots of junk on the stack and then blow away a large chunk of
stack all at once. The problem is that you need to copy the active
objects off of the stack, which normally requires non-portable assembly
code. The trick is to realize that if you have a copying garbage
collector, the *garbage collector* already has references to the active
objects *and* knows the format of the objects--all in a portable way.
Therefore, if you trigger a garbage collection, all of the active
objects get copied off and now you can blow away the entire stack with
impunity. Therefore, you only take a setjmp/longjmp hit whenever you
overflow stack. It's very clever.
The paper is:
CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A.
http://home.pipeline.com/~hbaker1/CheneyMTA.html
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
