Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exception lifetime question #287

Open
yamt opened this issue Jan 24, 2024 · 6 comments
Open

exception lifetime question #287

yamt opened this issue Jan 24, 2024 · 6 comments

Comments

@yamt
Copy link
Contributor

yamt commented Jan 24, 2024

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?

@keithw
Copy link
Member

keithw commented Jan 24, 2024

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)

@yamt
Copy link
Contributor Author

yamt commented Jan 24, 2024

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

@keithw
Copy link
Member

keithw commented Jan 24, 2024

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.

@titzer
Copy link
Contributor

titzer commented Jan 24, 2024

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.

@yamt
Copy link
Contributor Author

yamt commented Jan 28, 2024

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
Copy link
Contributor Author

yamt commented Jan 29, 2024

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.
yamt/toywasm#134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants