feat: reference types argument

[Tarnadas]

This PR adds a new argument --reference-types, which enables reftype compilation for wasm-bindgen.

This feature is hoped to enable more efficient communication between the host (JS) and the wasm module, but not yet all browsers support it.

For more information about reference types, you should read the wasm-bindgen Guide.

This argument will automatically disable wasm-opt.
Otherwise compilation would crash with the following error:

[parse exception: Only 1 table definition allowed in MVP (at 0:4234)]
Fatal: error in parsing input

[Urhengulas]

Hello @Tarnadas 👋🏽

The patch looks great :)

You should be able to make wasm-opt run successfully by passing the --enable-reference-types command line flag. This way you could still get the optimization 🚀

[richardlett]

I tried this out, and found this bug. Not sure if its related to this particular commit, or due to wasm-bindgen.

rustwasm/wasm-bindgen#2291

[Tarnadas]

This shouldn’t be related to this particular commit.

It rather sounds like a memory allocation issue, which might be totally normal. I’m not sure if there is an option for wasm-bindgen to increase the initial memory size, but you could do it manually in the generated JS glue code file and see if that fixes your problem:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Memory

Also I don’t quite get why this shouldn’t happen without reference types enabled.

Btw today I will be fixing the wasm-opt stuff. Thanks for the hint @Urhengulas

[richardlett]

Excuse my ignorance on javascript/wasm.

I cant seem to find in the glue code where to memory is allocated -- I can find a buffer with ref-types disabled, as there is a "heap", but I can't see anything of the like here.

Strangely, even if I'm just missing that, I preallocated using Vec::with_capacity(1 million), (which is not included in the benchmarks), and the issue is totally outside of that (and there's no further allocations are made besides the Vec, unless the gluecode is doing it somehow, but that does not seem to be the case).

[Tarnadas]

Apparently the JS glue code does not instantiate a WebAssembly memory, which would result in the default values being used.

You should see a line in your JS glue code which looks somewhat like this:

const wasmModule = new WebAssembly.Module(bytes);
const wasmInstance = new WebAssembly.Instance(wasmModule, imports);

Here you can instantiate a WebAssembly Memory with a larger initial size:

const wasmModule = new WebAssembly.Module(bytes);
const wasmInstance = new WebAssembly.Instance(wasmModule, {
  js: {
    mem: new WebAssembly.Memory({ initial: /* large number */, maximum: /* large number */ })
  },
  ...imports
});

[Tarnadas]

Unfortunately adding the --enable-reference-types to wasm-opt doesn't do the trick. I still get the same error.

Should we still accept the PR as is and add a tracking issue until this has been fixed by either wasm-bindgen or wasm-opt?
What do you think @ashleygwilliams?

[whatisaphone]

The corresponding flag for wasm-bindgen is called --reference-types. Maybe we should use the same longer name here for consistency?

[Tarnadas]

That sounds definitely like a good idea. I’ll update my PR, but I’m a little worried about the maintenance of this repository

[Tarnadas]

Hey @drager @azriel91,
I just rebased my PR with the latest master branch.
Any chance this could be reviewed and merged?

[azriel91]

@Tarnadas heya, I'm simply a fellow contributor; that said the changes look good ✌️

[cataggar]

The changes look good to me.

[Tarnadas]

Hey, I haven’t looked into this for a very long time. Maybe we no longer need to disable wasm-opt. Has it been updated in the meantime?

[mikefarmer01]

This should generate at least a debug message to notify the user that wasm-opt had been disabled.