Reintroducing exnref

[titzer]

In (https://github.com/WebAssembly/meetings/blob/main/main/2020/CG-09-15.md), the EH proposal was changed to remove exception packages as first class values. Since that time, this proposal was advanced to phase 3, implemented in the reference interpreter, in toolchains (LLVM and Binaryen), and implemented in all 3 web engines. Web browsers have subsequently enabled the feature by default. Today, there are web properties and applications that use the feature and thus there are binaries that use the feature for C++ exception handling in the wild.

Given those constraints, making any change to the proposal requires careful thought and consideration, as any change we do make could have a potential disruptive effect on producers, toolchains, and engines, and even deployed applications on the web. This proposal has also undergone a number of changes and long design discussions over the years that have taken a lot of time and energy to work through and resolve.

That said, offline discussions have led me to propose that we find a deft way to reintroduce exnref to this proposal, within a set of hard constraints. I am led to this because exnref solves a number of problems that weren’t fully anticipated when it was removed and were only encountered after-the-fact.

Problems

Several issues were identified that are either directly related to lack of exnref or related to the lexical rethrow construct introduced to avoid exnref, which adds a new form of storage to Wasm.

1. Difficulty in handling the identity of thrown exceptions in the JS API spec.
2. Complexity in the formal specification around lexical rethrow.
3. Engine complexity around lexical rethrow, e.g. interpreters.
4. Inability to CPS-transform (e.g. asyncify) Wasm functions with exceptions.
5. Lack of exnref significantly restricts toolchains’ code transformations and sometimes leads to unnecessary duplication. (Specific feedback from J2CL authors).

Opportunities

Reintroducing exnref addresses the above problems and allows us to further improve the EH proposal.

1. Simplification of formal specification.
2. Simplification of JS specification.
3. More opportunities for factoring exception handling code, e.g. it could be outlined into other functions.
4. Simplification to engine decoding and validation.
5. More leeway for code transformation and optimization in toolchains.

Constraints

We’re operating under a number of tight constraints and requirements.

1. Don’t break the web. Binaries that work today must continue to work in the presence of adding exnref to the spec, up to some deprecation threshold (2).
2. Should we decide to deprecate any part of the existing proposal, we must offer an (automated) migration path for binaries in the wild.
3. Support asyncify/CPS transform.
4. Avoid protracted design exploration. From offline discussions, there is no energy for any fundamental redesign among key stakeholders.
5. Must document Web reality. The status quo of the proposal (i.e. Phase 3) has been “stable” and in browsers for more than a year. How it works should be documented with appropriate rigor, even if the final proposal were to deprecate any functionality.

Related issues/links

“Ambiguity/identity loss when (re)throwing external exceptions” #207

“Should wasm code be able to extract the externref from exceptions thrown from js?” #202

“Clarify how exception identity is tracked” #242

“Update JS API to better specify opaqueData exception identity” #250

“Issues discussed in J2CL” #158

[titzer]

Also note: there is an item on the August 1st meeting agenda to discuss EH.

https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-08-01.md

[titzer]

Slides from today's meeting: https://docs.google.com/presentation/d/15LAJ7VfE_68mgolMgeg9AEJbrrEGoNkEOXhG1J6_5W0/edit#slide=id.p

[keithw]

Thank you for the presentation today! I hadn't been following this conversation. I implemented the exception-handling support in wasm2c. One of the things that made that easier is the (current) lexical scope for storing caught exceptions. Right now wasm2c doesn't even copy a caught exception onto the stack unless that particular caught exception is the target of a later rethrow, which is easy to identify once you get to the rethrow instructions.

Option A and Option B seem to make life a bit harder for consumers like wasm2c, in that I think in practice they'd require that all caught exceptions will have to be stored somewhere with indefinite lifetime and dynamically known size. So I think there would now need to be a malloc at the start of every sequence of catches, and the runtime would need some sort of GC or a system of refcounting + an API for host functions to honor the refcounts when copying or storing these types. Which all feels less-than-ideal.

How would you and others feel about an "Option C," which roughly speaking would look something like this?

• Preserve the existing EH proposal, and add no new types, but
• Perhaps in a new named feature/proposal ("enhanced EH"?), add three new instructions or standardized func imports:
  • make_exnref: [] → externref. Returns the current caught exception as an externref
  • free_exnref: externref → []. Frees the object created by make_exnref
  • rethrow_exnref: [t₁* externref] → [t₂*]: Rethrows a caught exception. Traps if the externref is invalid (e.g. has been freed, is not an exception).

I'm definitely not an expert in the formal semantics of exception handling, but if something like this could be made to work, it seems like the benefits would be things like:

• It could layer nicely on top of the current EH proposal, without deprecating or duplicating anything that already exists
• malloc would only become necessary when explicitly invoked by make_exnref (rather than every time there is a catch or sequence of catches)
• The lifetimes of exnref objects would become explicit and the responsibility of calling code. Of course an engine is still welcome to GC or refcount exnref objects itself if it chooses. (With wasm2c, the runtime would probably stick them all in a list and provide an API call to let the embedder destruct the whole context.)

Curious if this something like this is feasible.

[conrad-watt]

Option A and Option B seem to make life a bit harder for consumers like wasm2c, in that I think in practice they'd require that all caught exceptions will have to be stored somewhere with indefinite lifetime and dynamically known size.

I think this specific concern is something that could be addressed by the variant of Option A that @titzer mentioned, where the existing "exnref-less" catch is maintained alongside the new catch-with-exnref. Catch bodies without an associated rethrow could continue using exnref-less catch, so the materialisation and storage of an exnref wouldn't be required in these cases. I acknowledge that this wouldn't address the wider concern that any refcounts/GC would be a new implementation concern for wasm2c though.

I think an instruction-set with an explicit deallocation instruction for exnref would be somewhat out-of-step with the direction of other proposals (e.g. GC types and stack switching).

[keithw]

Thinking about how we'd implement exnref in wasm2c, honestly I think we'd probably just represent is as a fixed-size value type on the stack (probably a struct that contains the tag type, the length of the serialized tag values, and the serialized tag values themselves). We already enforce a maximum size of a serialized exception at 256 bytes, so I think we can just do this and avoid any mallocs, refcounting, or GC. (Edit: Although this strategy wouldn't work for us if a tag type is allowed to contain an exnref...)

It would be very easy to implement some added instructions like:

• make_exnref: [] → exnref. Returns the current caught exception as an exnref. This could also take a labelidx immediate (similar to today's rethrow), which would let it capture any caught exception as an exnref (just like rethrow can rethrow any caught exception).
• rethrow_exnref: [t₁* exnref] → [t₂*]: Rethrows a caught exception.

It seems like these could be layered nicely on the current design without needing to deprecate anything.

---

Re: last comment, I don't think I understand the value of catch-with-exnref specifically. In a catch clause, the code knows the tag type and has the tag values. If that was all there was, it seems like it already has all the information it could want to freeze/rethaw the exception. The challenge seems to happen when we're talking about capturing a long-lived reference to an exception that was caught in a catch_all clause. In that situation, you don't know the tag type (it may not even be in the module) and can't get at the values, so there needs to be some opaque way to refer to them.

[conrad-watt]

The challenge seems to happen when we're talking about capturing a long-lived reference to an exception that was caught in a catch_all clause

Sometimes we'll want to capture a long-lived reference to an exception that was caught in a regular catch clause too (my understanding - for code de-duplication and more complex interaction with JS). An idea in the style of make_exnref would also facilitate this, but wouldn't address the underlying concerns that some participants have expressed about our current lexical rethrow (hence the expressed desire to deprecate it if we're adding exnref) - my understanding is that all many of the same concerns could be identically expressed about a lexical make_exnref.

[aheejin]

@keithw

Thinking about how we'd implement exnref in wasm2c, honestly I think we'd probably just represent is as a fixed-size value type on the stack (probably a struct that contains the tag type, the length of the serialized tag values, and the serialized tag values themselves). We already enforce a maximum size of a serialized exception at 256 bytes, so I think we can just do this and avoid any mallocs, refcounting, or GC. (Edit: Although this strategy wouldn't work for us if a tag type is allowed to contain an exnref...)

I was thinking in a similar vein. Without GC objects, exceptions only can contain primitive types, and I don't think this could be very different from handling multivalue types, in case wasm2c already supports them. As you said, this is not gonna support the exnref within exnref, but I think it's fine to just error out in that edge case; I can't imagine why anyone would want to do that.

It would be very easy to implement some added instructions like:

• make_exnref: [] → exnref. Returns the current caught exception as an exnref. This could also take a labelidx immediate (similar to today's rethrow), which would let it capture any caught exception as an exnref (just like rethrow can rethrow any caught exception).
• rethrow_exnref: [t₁* exnref] → [t₂*]: Rethrows a caught exception.

It seems like these could be layered nicely on the current design without needing to deprecate anything.

As @conrad-watt said, make_exnref depends on the surroundings and also becomes lexical, so it would have the same problems with the rethrow.

By the way I'm wondering, is the number of exnrefs on the fly the problem? Semantically whether catch returns an exnref or make_exnref returns an exnref doesn't seem to make much difference. (But I also wonder, even in the case the number is too large, can this be solved if we limit the value types to primitive types, as I said above?)

[aheejin]

@conrad-watt

I think this specific concern is something that could be addressed by the variant of Option A that @titzer mentioned, where the existing "exnref-less" catch is maintained alongside the new catch-with-exnref. Catch bodies without an associated rethrow could continue using exnref-less catch, so the materialisation and storage of an exnref wouldn't be required in these cases. I acknowledge that this wouldn't address the wider concern that any refcounts/GC would be a new implementation concern for wasm2c though.

The current C++ implementation needs rethrow in, I guess, at least more than half of the cases. One case is for destructors:

try
  ... running destructors ...
catch_all
  rethrow
end

The other case is in try~catch, and the exception is not the right type:

try {
  ...
} catch (int) {
}

becomes something like

try
  ...
catch $cpp_tag
  if the thrown value is of type `int`
    do stuff
  else
    rethrow
end

So even if we have two different catches, one with exnref and the other without, I think wasm2c needs to be able to handle catch with exnref anyway. Also for the sake of simplicity it is likely the toolchain will use the version with exnref for all cases. (catch (not catch_all) doesn't account for much in programs, so the code size increase will be not really noticeable)

[keithw]

I got to talk today with @aheejin, @conrad-watt, and @titzer, about the implementability of exnref in wasm2c, and probably in other "offline" VMs that also lack GC.

The conclusion seemed to be that we agree there's a workable outcome where (for purposes of the current proposal):

• It would be malformed for a tag type to include an exnref param
• There would be a new implementation-defined limit on the number of parameters in a tag type (distinct from the existing limit on the number of parameters in a function type), and
• People think it's reasonable for an implementation to set that limit at, like, 32

If the spec ends up this way, then I think implementations would be able to treat exnref as an "exception sum type," i.e., as a POD type big enough to contain any exception contents that gets copied when needed, and can avoid a dependency on GC.

All of these things might then be lifted in a future proposal. I hope that summarizes accurately!

(My personal preference would probably still be to maintain the status quo, both because it's already implemented and because I think it will perform marginally faster, but I think as far as wasm2c and perhaps other offline VMs are concerned, the above wouldn't be a major hardship.)

[RossTate]

Thanks for doing this! I would recommend taking Option B a bit further: have two instructions catch $tag $label instr* end and catch_all $label instr* end indicating that exceptions (of the designated label) thrown from within instr* should be caught with $label as their handler. Bringing the label up front means the type-checker and compiler can know all local control targets of every function call while type-checking/compiling the call. So, as an example of how this might be helpful in the future, if the type of the $label says that local $foo must be initialized, the type-checker can know to check at every call site within instr* that $foo has been initialized.

[tlively]

@eqrion previously had a very similar idea, where he spelled it out like this:

try <blocktype> (catch <tag> <label>)* (catch_all <label>)? <instr>* end

I do like keeping the try syntax at the beginning, and we do still need the <blocktype> in the header as well in case there are no exceptions thrown. I also think it makes sense to allow catches and catch_all to be specified on the same try block, but I do agree that it would be nice to bring the labels up to the header before the instruction sequence.

[RossTate]

Works for me. Besides complicating parsing, my main concern with that was that the order of catch clauses is semantically significant (because two clauses can have the same tag), so I thought splitting the instruction into one handler at a time would make that clearer.

Does the exnref still have more content to it than just its tag and payload? If so, since it's a bit costly to use exnref on some engines, you might consider having two variants of the instruction(s): one that provides an exnref (on all paths), and one that does not (on any path).

Neither of these are big items for me; bringing the labels up front is the item I care more about.