Hi Ville,
On Fri, Dec 31, 2010 at 5:26 PM, Ville Voutilainen ville.voutilainen@gmail.com wrote:
The JVM clears the stack when it enters an exception handler (in Java
Minor clarification: the call stack frames are unwound rather than cleared. The stack doesn't clear completely, it unwinds to the catching frame.
If any values were stored on the stack, they're gone at that point, _unless_ they were pushed before invoking the throwing operation.
That's really not what I see happening in the verification process. What I see is that the stack of the current frame gets completely cleared. There's only 1 value on the stack when an exception handler is invoked, which is the exception object. Or at least, this is what the verifier assumes. This link (10th bullet) seems to support that: "When an exception is thrown, the contents of the operand stack are discarded." [http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#1...].
This is my point: we are currently doing things which - if written in Java - would look like this:
MyClass.execute(Symbol.KEYWORD, try { invoke_some_lisp_code(); } catch (Go g) { return-from-try ThisClass.constantValue; } );
which first puts Symbol.KEYWORD on the stack, but the stack gets cleared out when "catch (Go g)" is triggered.
I actually don't see how local variables are different, as both operand stacks and local variables are stored into call stack frames. If the frame is unwound, the values are gone.
Right. But the frame where the exception is "handled" isn't being unwound. It's stack is being cleared though; meaning that anything that was on that stack isn't anymore. *That* is our stack inconsistency issue.
If the frame and/or local variables are established before the throwing call, they still exist after a throw, otherwise not.
Well, this would have been great, because I don't see much of a stack issue here. But as I said, I see different behaviour. And for the first time in 2,5 years of searching the JVM spec, I found supporting documentation for it.
I hope this clears up some of the mysteries related to the hoops we have to jump through to work on the JVM?
Bye,
Erik.