[Ironruby-core] Entering try-catch with non-empty stack

Charles Oliver Nutter charles.nutter at sun.com
Mon Oct 1 21:49:36 EDT 2007

Sanghyeon Seo wrote:
> As a recent thread pointed out, this list so far have been more like
> ironruby-talk than ironruby-core. :)
> So, to start the discussion, I have a question. In
> tests/ironruby/Runtime/Block/test_closure, I see this comment:
> # TODO:
> # assert_equal(foo(&p)) were replaced by x = foo(&p); assert_equal(x)
> # known DLR bug (entering try-catch with non-empty stack)
> This looks like a same problem JRuby encountered and solved. As
> Charles is on the list, he could provide some insight. :)
> A good introduction to this issue from JRuby point of view was written
> by Ola Bini:
> http://ola-bini.blogspot.com/2007/08/pain-of-compiling-try-catch.html

I don't think this qualifies as a bug; both the JVM and the CLR prepare 
a new activation (and an empty stack) when you enter an 
exception-handling section. For a language like Ruby, where you can, for 
example, prepare arguments to a method call by doing a loop or 
begin/rescue that ultimately return a value, you need to be able to 
maintain the stack. XRuby's approach is to save the stack, but I don't 
believe they support all such situations. JRuby generates a new method 
for such situations, to allow the original activation maintain the same 
stack state. In theory both approaches work, but they both have their 
own complications. Currently we create what's called "synthetic methods" 
in the JVM to contain the body of e.g. a begin block attached to a 
rescue block. We may also have to do this for while blocks when there's 
a chance that stack state must be maintained. I think we can determine 
statically when we need to create synthetic methods and when we can't.

- Charlie

More information about the Ironruby-core mailing list