Implement exception objects.

[cfallin]

This PR implements exception objects: the data model required to support Wasm exceptions, integrated with Wasm GC.

It builds out support for defining exception types (based on function signatures), and a host API to allocate and examine exception objects. It does not yet tie this into any exception-throwing or -catching instructions (throw, throw_ref, try_table); that will come next.

The design is a little fiddly because the type system has a nominal aspect to it: tags are per-instance entities and exceptions are associated with tags. The stack-switching work already added support for tags analogously to other instance entities (memories, tables, etc.). But, notably, because they are a runtime concept, they are not types per-se. Their signatures are, though, and TagType is a thin wrapper around FuncType as a result. The Wasm proposal does not define any concrete type definitions for exception objects in the lattice, only providing top (exnref / (ref null exn)) and bottom (nullexnref / (ref null noexn)) types. In order to align with the way the rest of the GC system works, I've opted to define our own notion of structural types at the host API and type-interning layer built around the signatures; so all Wasm exception objects with the same func-type / signature are the same "type" as far as GC is concerned. The objects of that type are then associated with particular tag instances via runtime fields. In essence we are refining the Wasm types further to allow our implementation to precompute things (i.e., layouts); this is fine because this refinement is not exposed to Wasm.

[cfallin]

A few other missing bits that I will do before marking as ready:

• I haven't implemented the GC-disabled stubs yet.
• We'll need to think about how to hide this appropriately -- at the very least, behind the GC feature, but perhaps behind another feature flag as well, until we have the full exceptions proposal implemented? We don't enable exception support in wasmparser so no one will be accidentally fooled by a failure deep in unimplemented bits; but the presence of a host API may be misleading still.
• No fuzzing yet; I'll build that out once I have the rest of the exceptions proposal done too.

[alexcrichton]

Nice!

We'll need to think about how to hide this appropriately

Personally I think it's reasonable to keep this behind the gc feature flag for now and leave it at that. This won't bring in any significantly new runtime dependencies that gc doesn't already bring, so having it behind the same flag I think is reasonable. In that sense filling out similar-ish GC-disabled stubs for exnref I think is fine.

In the future this means that the hypothetical Config::wasm_exceptions knob will only be available with feature = "gc" and if the gc feature is disabled then this feature will always be disabled for wasmparser, effectively being where we're at today.

One hypothetical branch point we could reach in the future is to implement wasm exceptions entirely independently of wasm gc. In such a world we'd probably have a separate feature gate for exception-handling but in lieu of that I don't think it's necessary to add a new feature just for exceptions (assuming no new "substantial" runtime dependencies or such are needed, which AFAIK won't be the case)

---

As a small aside, it's a bit regrettable how much duplication in a sense there is necessary for this. Most of this PR looks like a copy/paste of the GC bits for structref but then edited to be for exnref instead. That's not a dealbreaker by any means and rustc more-or-less shoehorns these implementations to exactly what they are, but I also think it'd be reasonable if you see refactoring opportunities to apply them more aggressively too (e.g. what you did here with initialization/reading struct fields and refactoring that so exceptions can use the same path)

[alexcrichton]

The design is a little fiddly because the type system has a nominal aspect to it

Oh one thing I forgot, are you familiar enough with the JS API for exceptions to say whether or not the approach here is roughly analagous? I don't know myself what the JS API looks like so I'm not sure myself.

[github-actions]

Subscribe to Label Action

cc @fitzgen

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"

Thus the following users have been cc'd because of the following labels:

• fitzgen: wasmtime:ref-types

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[cfallin]

Oh one thing I forgot, are you familiar enough with the JS API for exceptions to say whether or not the approach here is roughly analagous? I don't know myself what the JS API looks like so I'm not sure myself.

As far as I can tell, this is pretty close to both the Wasm JS API and the host API outlined in the spec, modulo requiring the ExnRefPre explicitly in our case whereas the above APIs allow one to allocate an exception object solely with a runtime tag reference and payloads. This is more-or-less in line with the way we support allocating e.g. struct objects too -- separating the layout lookup/computation is a reasonable performance optimization IMHO.

[cfallin]

One hypothetical branch point we could reach in the future is to implement wasm exceptions entirely independently of wasm gc. In such a world we'd probably have a separate feature gate for exception-handling but in lieu of that I don't think it's necessary to add a new feature just for exceptions (assuming no new "substantial" runtime dependencies or such are needed, which AFAIK won't be the case)

Yeah, I thought about this quite a bit before building out this part of the proposal: I was wondering whether the two (exceptions and GC) could be kept orthogonal as much as possible, largely to avoid the effort in this PR. An exnref would then be more like an externref; maybe held as an Option<Box<Exception>> in a table on the Store or something like that. In the end I didn't like that for three main reasons: (i) exception objects can store GC refs as payload, so when both are enabled, one needs special handling anyway to trace edges in both directions; (ii) it's quite a lot of duplicated effort (computing how to lay out values in a struct-like container, handling layouts and interning them, etc.); (iii) if one addresses problem (i) by having a separate exnref implementation for with-GC and without-GC, then one has two code paths to test and that's awful. Plus in practice most users of exceptions will likely want GC too. (Perhaps with the exception of a setjmp/longjmp use-case in wasi-libc?) Or to summarize all the above: GC has enough overlap with exceptions that they just need to interact, so we might as well handle them with common bits.

As a small aside, it's a bit regrettable how much duplication in a sense there is necessary for this. Most of this PR looks like a copy/paste of the GC bits for structref but then edited to be for exnref instead. That's not a dealbreaker by any means and rustc more-or-less shoehorns these implementations to exactly what they are, but I also think it'd be reasonable if you see refactoring opportunities to apply them more aggressively too (e.g. what you did here with initialization/reading struct fields and refactoring that so exceptions can use the same path)

Yeah, I don't like it too much either; but several alternatives I considered didn't feel great either. In particular one could imagine either using more dynamism internally (having a "struct or exception layout" that knows its kind dynamically and has the appropriate dynamic checks) or using traits or macros to factor out method implementations. In the end the surface bits needed to be separate for clean typesafe API reasons and the rest kind of fell out of that. Happy to take any particulara suggestions for refactors if anyone has any though!

[alexcrichton]

I was wondering whether the two (exceptions and GC) could be kept orthogonal as much as possible

FWIW I agree with your conclusions as well. I mostly brought this up to say that I think it would warrant a separate feature in such a hypothetical alternative world, but given the current implementation I don't think this warrants a separate feature or anything more than gating behind GC.

In the end the surface bits needed to be separate for clean typesafe API reasons and the rest kind of fell out of that

FWIW this is mostly my takeaway as well. It's wordy, but easy to read and verify it's right. The downside is that if it's got a bug (which would likely be preexisting if any) there's a lot of places to chase down. I think it's best to leave that for the hypothetical future in which we discover this though. Otherwise though I don't have any silver bullet suggestions myself either.

[tschneidereit]

is effectively resolved.

Does this allow us to set the allocation to 0, or something really very small? Because if it still requires at least one host page size of memory, I'm not sure it really is effectively resolved for all use cases.

Besides memory usage, I'm also concerned about the code size increase we incur by forcing the inclusion of full GC support for exception handling. Do we have a way to quantify / at least very roughly estimate how much larger a size-optimized binary becomes because of that?

[sunfishcode]

It wouldn't be too bad to do an "unboxed exceptions" implementation that directly copies payload values and supports only catch clauses and throw

In the Lime series, we do have the ability to subset features, for exactly this reason, so perhaps we should to that for EH too.

It seems likely that other engines will want a subset too. And the setjmp/longjmp used by LLVM and wasi-libc already uses just catch and throw.

[fitzgen]

Meta note: I am going to file a follow up issue for this discussion. Once I do so, let's move all this discussion there.

[fitzgen]

Meta note: I am going to file a follow up issue for this discussion. Once I do so, let's move all this discussion there.

Filed #11256