Rework JS API spec implementation limits#2089
Rework JS API spec implementation limits#2089bvisness wants to merge 1 commit intoWebAssembly:mainfrom
Conversation
rossberg
left a comment
rossberg
left a comment
There was a problem hiding this comment.
This all looks good to me. Have you compared by any chance whether the new limits introduced here are also listed in the core spec's Appendix? I wouldn't be surprised if that also has some gaps regarding newer features.
|
I don't think I've introduced any new limits. The core spec already allows syntactic limits on everything here (including both the number and size of elem segments), and execution limits on the size of tables and memories. GC things are well-covered by the core spec too. If it looks like I added any limits here, it's either because it was missing from the JS API spec only, or just part of the general refactoring I did to the section. |
| To <dfn>compile a WebAssembly module</dfn> from source bytes |bytes|, perform the following steps: | ||
| 1. Let |module| be [=module_decode=](|bytes|). If |module| is [=error=], return [=error=]. | ||
| 1. If [=module_validate=](|module|) is [=error=], return [=error=]. | ||
| 1. If any <a href="#limits-compile-time">compile-time limits</a> are exceeded, return [=error=]. |
There was a problem hiding this comment.
Note: This means that WebAssembly.validate will always fail when a module exceeds a compile-time limit, and should never fail when exceeding a runtime limit (even if instantiation would fail).
| 1. Let |result| be [=module_instantiate=](|store|, |module|, |imports|). | ||
| 1. If |result| is [=error=], throw an appropriate exception type: | ||
| * A {{LinkError}} exception for most cases which occur during linking. | ||
| * If a <a href="#limits-runtime">runtime implementation limit</a> is exceeded, throw a {{RangeError}}. |
There was a problem hiding this comment.
This is the case that covers e.g. a table with an initial size of 10,000,001 elements. Under this update to the spec, this would pass WebAssembly.validate and WebAssembly.compile but would always fail to instantiate due to this line.
2 participants
Resolves #1863 by reworking how implementation limits are organized, and drawing a clear distinction between compile-time and runtime limits.
I have currently made the decision to throw a RangeError when instantiating a module that trips a runtime resource limit, e.g. instantiating a module with a table whose initial size exceeds the implementation limit. This was already reflected in some tests and mirrors what happens if constructing an oversize resource from JS, e.g. new WebAssembly.Table.
I've left a couple inline comments to highlight the impact this spec will have on engines.
A couple other things to note:
memoryandtablefolders and memory64 limits are only checked in test files with-memory64in the name, following what seems to be an existing pattern. However, I honestly have no idea where we're supposed to have tests for this stuff, since the WPT tests in this repo and in the main WPT repo are wildly out of sync, so please tell me if I should organize things differently.Important: Currently no major engines pass all of these tests. SpiderMonkey throws RuntimeError where I think we should now throw RangeError, V8 rejects tables at compile time when it should reject them at instantiation time, etc. This suite of updates attempts to resolve those discrepancies, but it's less clear than usual which behavior we want.