exception-handling
exception-handling copied to clipboard
exception lifetime question
reading the latest overview https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md to me, it seems that some kind of GC is assumed to track the lifetime of an exception referenced by exnref. is it right?
I don't think so -- my understanding is that in a GC-less profile, exnref will be constrained so that runtimes can represent it as a copyable value type of reasonable size (a sum type / variant of any possible exception), rather than as a reference.
In particular, in the GC-less profile, it will be malformed for a tag type to include an exnref param, and there will be an 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) that could be set small enough so that a max-size serialized exception is small enough to keep as a value and copy as needed.
Discussion here: https://github.com/WebAssembly/exception-handling/issues/280#issuecomment-1664945711
ok. then, GC-less runtimes need to be able to handle huge values, right? (at least far larger than v128)
I think that's probably right, although the rules haven't been written down formally yet afaik. I think plausibly the spec could say that the implementation-defined limit is on the total size of values in a tag type (rather than the number of values), and a reasonable value for the limit could be 16 bytes (one v128, two i64's, or four i32's) without breaking real modules in practice.
What @keithw said. Note that his suggestion is just one possible implementation strategy. It would also be possible to reference-count them, since they cannot form cycles. A tracing of GC would of course be a correct implementation. Since Wasm up-until-now has no other GC requirement, adding GC of just exnref
could be done with a stack scan looking for roots, with no transitive closure required.
With Wasm GC being now Phase 4, the tracing option would only apply in the no-gc profile that will be later defined.
It would also be possible to reference-count them, since they cannot form cycles.
my understanding is that, funcref can already form cycles and exnref can be a part of such cycles. am i missing something?
I don't think so -- my understanding is that in a GC-less profile, exnref will be constrained so that runtimes can represent it as a copyable value type of reasonable size (a sum type / variant of any possible exception), rather than as a reference.
In particular, in the GC-less profile, it will be malformed for a tag type to include an exnref param, and there will be an 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) that could be set small enough so that a max-size serialized exception is small enough to keep as a value and copy as needed.
Discussion here: #280 (comment)
FYI, i implemented EH in toywasm that way. https://github.com/yamt/toywasm/pull/134