Adjust js-api spec's table implementation-defined limits #103
Conversation
|
I don't think we want to do this. The intent of adding table64 was to enable i64 function pointers, not to allow dramatically larger tables. In particular, in SpiderMonkey we have not relaxed our implementation limit on the actual size of tables, nor do we actually allow i64 tables larger than 2^32 items, as all tables are subject to the same runtime limit: https://searchfox.org/mozilla-central/source/js/src/wasm/WasmConstants.h#1150 It's important to recognize that this implementation-defined limit in the JS API has nothing to do with validation, even when constructing new tables via the JS API. |
| @@ -1780,7 +1778,7 @@ An implementation must throw a {{RuntimeError}} if one of the following limits i | |||
| In practice, an implementation may run out of resources for valid modules below these limits. | |||
|
|
|||
| <ul> | |||
| <li>The maximum size of a table is 10,000,000.</li> | |||
| <li>The maximal initial or maximum size of a table is 10,000,000.</li> | |||
There was a problem hiding this comment.
This is incorrect. This is a runtime condition; it's about the actual size of the table, not the limits.
|
I think the whole section is a bit unclear and needs clarification. Thanks for working on this, Eva! In the first section about CompileErrors we probably want to say that the maximum initial size is 10M. Otherwise the module is invalid. In the second section we mean that there is a dynamic limit of 10M; no table can ever grow bigger than that. This means that we return The declared maximum is not restricted by any of this. |
|
Our implementation throws a RuntimeError when constructing a Table through I do think the spec is confusing about this as it currently stands. I think the cases we need the JS API spec to cover, and be clearer about, are:
|
No description provided.