ZipPy status update

[Stefan Marr]

Hi Christian,
Hi Chris:

I was wondering about alternative solutions for non-local returns.
Christian, you said:

> 1) Major: (OptimizedCallTarget.java:214) Method.execute(Method.java:72)
> This method calls a method #messageSendExecution which contains a lot of control flow and allocations  [4] . Speculate on the fact that all of this code is not required. It contains a while loop + a lot of exception catches. I think on the fast-path it could just call the body of the method.

The first thing, I noticed after you pointing me there, is that I was able to remove some of the complexity, because I intrinsified while loops, and don’t need support for the control flow exception anymore. However, that still leaves me with this:

  protected static Object messageSendExecution(final VirtualFrame frame,
      final ExpressionNode expr) {
    FrameOnStackMarker marker = Arguments.get(frame).getFrameOnStackMarker();
    Object result;

    try {
      result = expr.executeGeneric(frame);
    } catch (ReturnException e) {
      if (!e.reachedTarget(marker)) {
        marker.frameNoLongerOnStack();
        throw e;
      } else {
        result = e.result();
      }
    }

    marker.frameNoLongerOnStack();
    return result;
  }

So, the while loop is gone. We just got the exception handling for non-local returns.
You said, speculate that you don’t need that. And I am now wondering whether I could go further than what you see above.

Chris, how did you solve non-local returns for Ruby? I suppose Ruby’s return is more or less similar to Smalltalk’s?

For SOM, I need to be able to return to the correct lexical scope, i.e., I want to return from the outer lexical method that’s still on the stack. However, in addition, I need to unwind the stack, and mark frames as ‘unwound’/removed from the stack in order to be able to handle blocks correctly that were return from a method, and were the outer activation does not exist anymore. Here, a non-local return just doesn’t have a good semantic, and needs to raise an error.

So, I guess, this means, the only time I do not need this exception handling here is when a method does not define any blocks in its body. Chris, do you do that kind of special casing?

Thanks
Stefan

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525