This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: continuation and multi-threading


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Do you understand Keisuke's VM well enough to say that breaking the
> stack into frames would be a viable solution?  (I ask this because I'm
> interested, not because I want to put you on slippery ground.)
> 
> Can you describe the gain of doing this?

I don't understand his VM (after all, I haven't seen the source yet),
but the idea is rather general.

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.

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).

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.

-- 
How to eff the ineffable?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]