[armedbear-devel] [rfc] Preventing stack inconsistencies - structurally

[Erik Huelsmann]

Hi Ville,

On Fri, Dec 31, 2010 at 5:26 PM, Ville Voutilainen
<ville.voutilainen at 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#11914].

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.