`finally` support?

[aheejin]

We have an old issue #11 for this, but it is 4 years old so I think it is worth opening a new one.

Recently Google's J2CL team is using wasm and they asked for finally to be added in the spec, citing the complexity of code duplicating transformation in case there are many branches/returns from the try part and also code size increase, which I think is a valid concern. Without finally, in case we have four ways of exiting a try block, such as 1. normal fallthrough 2. exception 3. return 4. branch, we might end up duplicating the same code four times.

finally support was discussed briefly years ago in #11, but people thought it could be transformed into try-catch with code duplication so it was not strictly necessary, but I'd like to ask you on your opinions now again.

@jakobkummerow suggested implementing it in the engine may not be trivial either, but it can be still worth having it in the spec because of the code size.

I cc'ed some people who might be interested or working on EH now + and also the J2CL team, but please feel free to comment even if I missed you. cc @tlively @dschuff @jakobkummerow @ecmziegler @thibaudmichaud @manoskouk @ioannad @takikawa @rluble @gkdn @rossberg @RossTate

[RossTate]

In #124, I offered the suggestion of having an "unwinding" variant of branching/returning instructions that would run all intermediate unwind blocks.

[aheejin]

@RossTate True, but we decided to remove unwind in #156. I think unwind + your variant of branching/returning instruction in effect achieves the same thing with finally.

[RossTate]

Oh, you were suggesting adding a finally block directly to wasm. Sorry, I misunderstood your post as looking for a way to support surface-level finally blocks within wasm. That would seem odd to me given your decision to remove unwind. finally blocks need to work with both dynamically scoped exceptions and lexically scoped branches/returns. As we discussed (and as I believe @phoe discussed in his presentation on non-local control), the rethrow instruction in catch_all makes it ill-suited for lexically scoped branch/returns. So finally blocks would need to not have a rethrow instruction. That would make them like unwind blocks. This means that you'd have to generate "unwinding" code differently for catch_all and finally (and maybe likewise for resolving unwinding mismatches?). The suggestion in #124 let you use the same unwinder code for both use cases, using the simple unwinding modifier on branches/returns to distinguish the two.

In short, I would expect any design with direct support for finally would be trivial to extend with unwind, making it unclear why we have catch_all. I understand that this has all been discussed before, which is why I am confused by the suggestion to add direct support for finally at this point.

[aheejin]

@RossTate I'm not sure if I understand what you are suggesting, and I also am not sure if we want to repeat the discussion between unwind vs. catch_all again. Also didn't really understand well what you meant by dynamic vs. lexically scoped, because we already have exceptional control flow anyway like throw and rethrow. (not necessarily in finally, but elsewhere)

I get finally and your proposal (unwind and unwinding branches and returns?) achieve the same thing. But finally can be one more instruction, but yours will require unwinding variant for every existing branch and return instruction: br, br_if, br_table, return, return_call, and many more branch instructions in the GC proposal: br_on_null/br_on_non_null, br_on_func/br_on_non_func, .... Is there a reason we should choose this path?

The suggestion in #124 let you use the same unwinder code for both use cases, using the simple unwinding modifier on branches/returns to distinguish the two.

Is this any different for finally?

[aheejin]

Also what we should think about are:

• What happens when catch throws or rethrows? In Java finally should run anyway. Then how should we define the semantics of catch's throw's argument, or in case of rethrow, how should we manage the rethrow's stack? Should we do a bookeeping of catch's argument (or rethrow stack) before running finally and after running finally throw the catch's exception?
• What happens catch throws or rethrows but finally also throws or rethrows? (@RossTate suggested finally shouldn't rethrow, which I am yet to understand why, but I think this question is separate, because finally at least can just throw) In Java semantics, catch's exception is discarded and finally's exception is honored. Is this the semantics we want to pursue here too?

[RossTate]

Also didn't really understand well what you meant by dynamic vs. lexically scoped, because we already have exceptional control flow anyway like throw and rethrow.

Exceptional control flow can be either dynamically scoped or lexically scoped. throw is a form of dynamically-scoped non-local control—it's non-local in that it can cause control to transfer outside of a function in some way besides returning, and it's dynamically-scoped in the sense that one traverses the stack to find out where to transfer control to. In lexically-scoped control transfer, the target is determined without inspecting the stack. br and return are forms of local lexically-scoped control transfer. return-from and go in Common Lisp are both forms of non-local lexically-scoped control transfer (with non-local usages provided in @phoe's presentation). Two-phase exception handling is a combination of continuation marks (the generalization of dynamically scoped variables that Matthew Flatt just presented) and lexically-scoped non-local control—one uses stack inspection to enumerate through the potential handlers, calling them in sequence until the handler does not return and instead uses a lexical non-local control transfer to jump to the "catch" code that the handler determined to be the appropriate match for the exception.

but yours will require unwinding variant for every existing branch and return instruction

From #124: "One way we could enable this is to introduce an unwinding instruction that must precede a branching instruction, and its semantics is to modify that branching instruction to execute the unwinders in unwind clauses as it cleans up the stack."

That said, you could have finally be just a variant of unwind that effectively puts unwinding around every applicable instruction. A benefit of that would be to reduce code size (though unwinding can be a single-byte instruction). But it might also be problematic for code generation and optimization (as br and such now become context-sensitive, beyond just having to stay in a place where their target label is still in scope).

---

As for the questions, I get concerned when I see WebAssembly making such policy decisions. It suggests to me that we haven't developed the correct low-level mechanisms that would enable languages to implement their own policy within WebAssembly.

[jakobkummerow]

I am confused by the suggestion to add direct support for finally at this point.

As the OP says, the primary motivation is module size. When the J2CL team thought about how to support Java's finally in Wasm, they realized that (1) the obvious (/only?) solution with the currently proposed Wasm-EH feature set is to duplicate the contents of the finally-block, and (2) depending on the structure of the function, many such copies may be required. If the Wasm wire format supported the notion of finally-blocks, then the modules could remain smaller, and the copying could happen in the engine (if an engine chooses to implement it that way; on this level there may be viable alternatives).

We do not have specific numbers on the module size impact yet, as it isn't easy to get them (it requires implementing the duplication approach first).

[tlively]

#124 proposes an alternative system that unbundles the search for dynamic control flow destinations from stack unwinding. Such a system is inarguably lower level (i.e. more expressive) than the currently proposed system, but that extra expressiveness comes at a great complexity cost in terms of the number of new primitives introduced. Although the presentation and exposition of Common Lisp control flow primitives was illuminating, I do not believe we currently have a large and diverse enough set of language implementors to validate a design for more general low-level control flow and unwinding primitives. All that is to say that I believe we should keep the current discussion focused on the current proposal scope of single phase exceptional control flow.

As for the questions, I get concerned when I see WebAssembly making such policy decisions. It suggests to me that we haven't developed the correct low-level mechanisms that would enable languages to implement their own policy within WebAssembly.

I agree that it would be great to develop such mechanisms, but they should be developed in a separate proposal and in partnership with language implementors who would use them

---

With that being said, I would like to say that I am tentatively in favor of adding some form of finally to this proposal for the following reasons:

1. Although the JVM does not have a finally construct, the .NET IL does, so there is precedent to include finally in a similar exception system.
2. Avoiding code path duplication will make it easier to optimize code. For example, inlining heuristics will be better if a call in a source-level finally block is not duplicated.
3. Producers will be simpler if they do not need to compile source-level finally via code duplication.
4. Code size benefits.

I would propose adding try-finally as a new form in addition to the existing try-delegate and try-catch*-catch_all? rather than allowing constructs like try-catch*-catch_all?-finally?. I believe this would sidestep the tricky questions @aheejin raised about the interactions between catching, throwing, and finally blocks by leaving it up to the producer to nest the constructs correctly.

Another question to resolve is whether control flow transfers via try-delegate should run finally blocks or tunnel through them the same way they tunnel through catches. I would propose that try-delegate should tunnel through finally blocks without running them because the whole point of try-delegate is to behave as though the exception is being thrown from the delegate scope.

I would be less inclined to add finally to the proposal if it turned out that various source languages had different finally semantics that could not all easily be supported by a single addition to the spec. To my knowledge this is not the case, but I also haven't investigated it at all.

[aheejin]

@tlively

I would propose adding try-finally as a new form in addition to the existing try-delegate and try-catch*-catch_all? rather than allowing constructs like try-catch*-catch_all?-finally?. I believe this would sidestep the tricky questions @aheejin raised about the interactions between catching, throwing, and finally blocks by leaving it up to the producer to nest the constructs correctly.

I think splitting this is a good idea if it makes thing simpler. But I'm not sure how we should transform this code in Java:

try {
  foo();
} catch (Exception e) {
  throw e; // rethrow or throw, doesn't matter
} finally {
}

The problem is the finally should rethrow, or more precisely pass, the already thrown exception in case the finally is entered by an exception thrown, but the finally should just fall through in case the finally is entered by a fallthrough, and it should return in case it is entered by a return, and so on. @rluble @gkdn How do you plan to generate code for this difference in J2CL?

Another question to resolve is whether control flow transfers via try-delegate should run finally blocks or tunnel through them the same way they tunnel through catches. I would propose that try-delegate should tunnel through finally blocks without running them because the whole point of try-delegate is to behave as though the exception is being thrown from the delegate scope.

I agree finally should just tunnel through the exceptions delegated by delegate, for the same reason.

[fgmccabe]

The finally clause is not the one doing the throwing in this example.
In fact, in early Java implementations, the finally block was implemented using JSR (which is like a funclet). The finally code (void->void was run just before throwing.

[tlively]

The problem is the finally should rethrow, or more precisely pass, the already thrown exception in case the finally is entered by an exception thrown, but the finally should just fall through in case the finally is entered by a fallthrough, and it should return in case it is entered by a return, and so on.

Isn't this what the WebAssembly-level finally would do as well?

[aheejin]

The problem is the finally should rethrow, or more precisely pass, the already thrown exception in case the finally is entered by an exception thrown, but the finally should just fall through in case the finally is entered by a fallthrough, and it should return in case it is entered by a return, and so on.

Isn't this what the WebAssembly-level finally would do as well?

I guess so, but should we make spec decision finer-grained than that? For example, if we hold off on any throws from a catch to run it after finally body, how should we manage the value stack? By the time of throw we might have arbitrary number of values on top of the value stack to be used by the throw. How should we preserve that stack until the end of finally? Should we run finally in a shadow stack or something?

[tlively]

One possibility would be to require finally blocks to have type [] -> [] and to not give them access to any values that the control flow is carrying as it passes through the finally blocks, whether or not that control flow is exceptional. So finally would not be able to inspect or modify the values or exceptions associated with the control flow. I don't have a good sense of what languages this would or would not work for, though.

[tlively]

We also have to figure out what should happen to the in-flight exception or control flow payload if there is a branch (or return) out of a finally block and make sure that behavior is general enough among languages with exceptional control flow. @RossTate's point about leaving these policy decisions up to individual toolchains sounds nicer and nicer the more I think about this, so I hope we can do a low-level follow up proposal at some point :)

[fgmccabe]

finally blocks should definitely have type []->[]. Anything else is madness.