Implement table64 extension

[sbc100]

Now that #46 is decided we need get this extension implemented in various places:

• Overview
• Spec interpreter Update interpreter and test suite for table64 #53
• Spec text
• Resolve memory.copy / table.copy between memories / tables of different types (32-bit vs 64-bit) #55

External places:

• wabt (Update testsuite and implement table64 wabt#2418)
• binaryen ([memory64] Add table64 to existing memory64 support binaryen#6577)
• llvm ([WebAssembly] Use 64-bit table when targeting wasm64 llvm/llvm-project#92042)
• emscripten ([wasm64] Enable table64 lowering emscripten-core/emscripten#21992)
• v8 impl (https://g-issues.chromium.org/issues/338024338)
• spidermonkey impl (https://bugzilla.mozilla.org/show_bug.cgi?id=1893643)
• jsc impl

[dschuff]

Looks good, although I wouldn't consider wabt a blocker for phase 4 if we have support in Binaryen.

[alexcrichton]

My understanding of ocaml is shaky at best but by my read the current implementation of the binary encoding of a table type is to use the third bit of the prefix byte is used to indicate whether the index type is i64 (where if it's 0 then it's i32, as-is today). This makes sense for memories where the second bit was already claimed for the shared bit by the threads proposal, but I wanted to raise a question here if this is the desired encoding for tables. That means that the second bit in the table type prefix byte is currently unused.

Given the shared-everything-threads proposal it seems like we'll get a shared table type one day so thinking about this I think it might make sense to leave the hole, but I wanted to be sure to flag this and ensure that it was intentional and not accidental (e.g. I can see how it would be easy to just reuse what was already in the interpreter)

[sbc100]

Yes, the idea is tie match the flags that we use for memories.

For example, in wabt we have: https://github.com/WebAssembly/wabt/blob/356931a867c7d642bc282fff46a1c95ab0e843f3/include/wabt/binary.h#L24-L29 and these flags are used for both memories and tables. It makes sense to me to re-use these, even though we don't currently have shared tables. Are there downsides to doing this that you are thinking of?

[alexcrichton]

I don't think there's any downside to doing this, no. In Wasmtime we don't parse limits in the same way between tables/memories because for so long the encoding of tables/memories has diverged - for example for quite some times memories can be shared or 64-bit but tables can't be. Even with the table64 extension and a hypothetical shared table type the custom-page-sizes proposal still has different parsing of the flags byte which won't ever get mapped to tables.

Basically while the parsing of limits was trivially the same between memories/tables I don't think we should take it as a design guideline that they must match for all future proposals as well. The 64-bit-ness and shared-ness makes sense to match since we might as well, though.

[rossberg]

Unless there is a strong reason to do otherwise (like running out of bits), I think it's preferable to keep them in sync. (We have been doing the same for elem/data segments.)

[bvisness]

The SpiderMonkey implementation has landed in Nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1893643

Aside from the concerns laid out in #68, our implementation is ready for phase 4.

[sbc100]

Fantastic. Thanks for all the work on this. I think #68 is now the only blocker.

[sbc100]

@bvisness is there a command line flag I need to pass to spidermonkey to enable memory64? I'm trying to run some tests in emscripten CI.

[eqrion]

In the shell it should get enabled with -P wasm_memory64 (-P enables prefs). In the browser, about:config it should be javascript.options.wasm_memory64. I believe nightly builds have it enabled by default.

[sbc100]

Hmm.. I can't seem to make -P work:

$ /usr/local/google/home/sbc/.jsvu/engines/spidermonkey/spidermonkey -P wasm_memory64
Error: Invalid short option: -P
$ /usr/local/google/home/sbc/.jsvu/engines/spidermonkey/spidermonkey -Pwasm_memory64
Error: Short option followed by junk: -Pwasm_memory64