Re: continuation and multi-threading

[Keisuke Nishida <kxn30 at po dot cwru dot edu>]

Miroslav Silovic <silovic@zesoi.fer.hr> writes:

> You split your VM stack into chunks - doesn't matter how, but function
> call boundaries are the obvious borderlines. Then you can GC the
> individual frames, and they don't have to be contiguous in memory.
> 
> Then you can do different things to avoid copying. For example, copy
> the last frame, mark the other as read-only (possibly with a
> timestamp) on a call/cc, and copy as needed. Or use CPS, don't -ever-
> trully return from VM the functions, and use tail-recursion and gc to
> clean up the frames.

But in this case, I have to create a new frame object every time a
function is called.  Since function call is so popular, creating an
object there will lower the speed, increase GC time again, and also
make the VM complex.  I'm not sure if it is really worth doing.

If someone really wanted fast continuations, she could write a special
VM engine only for continuations, just as I have a debugging engine now.
Then, she could specify a compilation option that tells the compiler to
produce bytecodes for the fast-continuation engine.  But it's not me.

> The main advantage of frames is that they form a tree, which Scheme
> execution model kinda expects (especially for the environments,
> i.e. local variables).

My VM has a concept "external variables", which may form a tree.
Only those local variables that are referred from closures become
external variables and they are allocated specially.

> Hmm, this reminds me, if the local variables are kept on the stack,
> and that stack is copied, set! won't stick after invoking a
> continuation (contrary to R5RS). So you must keep local variables in
> frames anyway.

Hmm, right.  I didn't think of it.  I think I have to export all local
variables within a closure that uses call/cc as external variables.
This is not so hard, but very inefficient.