[MLton-devel] implementing raise and the exception stack

[Stephen Weeks]

We currently implement the exception stack by keeping a global
pointing to the exception stack top and having each exception stack
frame keep a link pointing to the next frame.  Then, a raise can go
immediately to the top exception frame.  But, we pay for setting the
link and the handler.

Neal mentioned to me today at lunch an alternative that some Java
compilers use.  They do not set the link and the handler, and instead
have raise walk the stack from the stack top to find the exception
stack top.  We could implement this by keeping some more information
associated with each frame, indicating whether or not it has a
handler, and if so, where.

I like the fact that with our approach we can get to the exception
stack top in constant time, and worry about the cost of raise with the
alternate approach.  But, it is clear that the alternate isn't that
bad because the cost of walking the stack can be amortized into the
time it took to push the stack frame in the first place.

I am mentioning this because I think it is something that we might try
whenever we get around to working exceptions paper again.

I am also wondering if there is a hybrid approach that might work.  We
could have a global flag that tells us whether or not we the
top-of-exception-stack global is valid.  Raise can then check this
flag, and if it is valid, jump immediately to the top of the
exception stack.  If not, it walks the stack.  Most of the time, we
don't bother to maintain the exception stack, but, whenever we're
about to enter a nontail recursion that might need to raise, we set
the flag and the top-of-exception stack global.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel