exception-handling icon indicating copy to clipboard operation
exception-handling copied to clipboard

exception lifetime question

Open yamt opened this issue 7 months ago • 6 comments

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?

yamt avatar Jan 24 '24 08:01 yamt

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

keithw avatar Jan 24 '24 08:01 keithw

ok. then, GC-less runtimes need to be able to handle huge values, right? (at least far larger than v128)

yamt avatar Jan 24 '24 08:01 yamt

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.

keithw avatar Jan 24 '24 18:01 keithw

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.

titzer avatar Jan 24 '24 18:01 titzer

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?

yamt avatar Jan 28 '24 05:01 yamt

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

yamt avatar Jan 29 '24 08:01 yamt