RE: [Sablevm-developer] Continuations (Part 2)

[Brent F. <bre...@xp...>]

> 1- At the bytecode level, exception handling is expressed quite
> differently from Java source.

Right, but there's a bytecode (Returnsub or something like that)
that might be usable?

> 2- If I remember my high level programming languages course correctly,
> the whole point of a continuation is to capture a snapshot of the
> "current" stack, so that you can later execute code in this same
> context, even if the current stack is unwinded.  In ML (or some
> dialect?) that allowed implementing "static binding" instead 
> of "dynamic binding" a la LISP.  The consequence is that the method
> in which the "create snapshot" occurs might return before you 
> "resume" and execute the continuation.  In which case your scheme
> wouldn't work, unfortunately.
> 
Understood.  I hadn't thought this through fully.  Drat.

> Please let me know if I am completely off track. (Quite possible!)
> 
> In fact, can you write for me a simple example that requires
> continuation?
> 
(Simple in Scheme, but ugly in Java -- see Part1).

> See below for additional questions.
> 
> > 3. JVM creates an exception that holds the current state of
> >    this routine (i.e., must make a copy of the current variables)
> 
> What is in the "saved" state?
> 
> - current stack frame?
> - stack (all frames) of current thread?
> - global variables (e.g. static fields)?
> - other stacks (stack of other threads)?
> - heap state (object instances?
> - other vm internal state (locks, ...)?
> 

Unknown.  It's almost like taking a snapshot of the VM at the moment
you hit the continuation.  But I'm not totally sure how it's typically
implemented.  I need to read through the http://www.nightmare.com/
(schintro-v14/schintro_3.html) stuff because it explains one implementaion
of this.

Anyway, probably not really worth worrying about just now.  :-)

-Brent