Adjust js-api spec's table implementation-defined limits

[evicy]

No description provided.

[bvisness]

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.

[bvisness]

This is incorrect. This is a runtime condition; it's about the actual size of the table, not the limits.

[backes]

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.
And I think we can keep the sentence about initializers.

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 -1 when trying to grow in Wasm and we throw a RangeError if growing via JS, right? Not sure why it's talking about throwing a RuntimeError.

The declared maximum is not restricted by any of this.

[bvisness]

Our implementation throws a RuntimeError when constructing a Table through new WebAssembly.Table(). It doesn't make sense for it to be a CompileError, after all, and since it's not a Table.grow it doesn't trigger the RangeError.

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:

• Hitting implementation limits when compiling a WebAssembly module
• Hitting implementation limits when creating WebAssembly objects like memories and tables directly
• Hitting implementation limits at runtime (usually?) (only?) through grows.

[backes]

Eva uploaded a new commit; we tried to make the wording more clear and removed the mention of a RuntimeError.
@bvisness can you check if this matches your understanding?