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: How often are continuations created?


Keisuke Nishida <kxn30@po.cwru.edu> writes:

> I am thinking of implementing cheap continuations for my VM
> by the following algorithm:
> [...]

This is basically the algorithm from the paper that you cited, right?

In the paper, they say that when you copy a stack, then you can't use
it to store local bindings that might get mutated.  This is because a
continuation would then also capture the values of these local
bindings and when a continuation is activated and the stack is copied
into place, the bindings are copied, too.  This would be wrong.

Copying the data stack should be no problem, because it contains no
mutable bindings, only intermediate results.  But copying the control
stack that has environment frames in it, will lead to the problem from
above.

Currently, Guile has that problem, too, but it is not significant.
This is because all Scheme environment frames are allocated on the
heap, and only C activation records are on the stack and get copied.
C is not Scheme and so can probably tolerate the different semantics.

[ But what happens with Hobbit? ]

So, it looks like you need to allocate bindings that might get mutated
in external frames, on the heap.

Is that right?

As a general guideline, I would strive to make executation fast when
no continuations are captured and or activated, and tolerate it that
continuations are significantly more expansive than function calls.  I
think that for each performance critical application of continuations,
there is a special purpose solution that can be cheap.  For example,
break/continue can be done by locally analyzable escaping
continuations that the compiler can turn into efficient code.
Multithreading is done without continuations anyway.  Backtracking
algorithms might have to suffer, tho...

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