feat(op2): implement fast wasm memory ops

[littledivy]

Closes #273

#[op2(fast)]
fn op_wasm(state: &mut OpState, #[smi] rid: u32, #[memory] memory: WasmMemory) {
  let memory = memory.get(state, rid).expect("invalid wasm memory");
  memory[0] = 69;
}

// Save memory handle for slow call access
const handle = ops.op_core_set_wasm_memory(instance.exports.memory);

// Expose op to Wasm module
const instance = new WebAssembly.Instance(module, {
  wasm: {
    op_wasm: () => ops.op_wasm(handle),
  },
});
instance.exports.call(rid);

[mmastrac]

I'd like to try and approach this a different way as the potential for possible footguns with this API is probably going to be a little too high.

See the comments inline for more details, but the #[memory] (or #[wasmmemory]) argument should probably just use the raw v8::WasmMemoryObject on the JavaScript side, and either a &[u8], or &mut [u8] on the Rust side.

The idea behind op2 is that all the complex, foot-gunny stuff should happen in the op code itself. So the magic in WasmMemory::get should actually get in the op-generated code.

This means that you should make the slow call of a wasm memory parameter require the state, and then fetch the wasm memory resource from that state in the slow path. You would then create the slice from it as we do for buffers and pass that to the code.

I also suspect this code might be broken when calling the op from JS, as the fastcall doesn't check to see if the fastcall options wasm_memory parameter is set.

I'd like to know a bit more about how these calls work from JS/WASM first -- are calls to functions with fast equivalents always fast in wasm mode? If so, I think we might actually want to have two operating modes for wasm memory: one being a "virtual" op for accessing the "fast" wasm memory (maybe something like #[memory(from_wasm)]?), and a second one being a "non-virtual" op that uses the underlying v8::WasmMemoryObject directly rather than using a resource intermediary.

[mmastrac]

This code worries me a bit because there's no guarantee that the scope is on the stack when it is called -- it is possible to create one of these via WasmMemory::null() and then call get on it.

As mentioned above, it would be better to hide this inside the op itself because we can make those guarantees there.

[mmastrac]

I think this particular construct is a bit too awkward -- what if we make #[memory] a non-virtual argument that takes the v8::WasmMemoryObject?

We do something similar to this already for buffers in both fast and slow mode.

It would look something like this:

#[op2(fast)]
fn op_wasm(#[memory] memory: &[u8]) {
 ...
}

[littledivy]

There can be multiple WasmMemory objects, hence it is stored in a ResourceTable and we need explicit access to state and rid.

[mmastrac]

Could we pass the actual v8::WasmMemoryObject instead of storing it in the resource table, though?

[littledivy]

It wouldn't be a fast call then

[mmastrac]

Why not? We allow for v8::Local<v8::Value> in fastcalls, so it should work? Or am I missing something?

[mmastrac]

Bikeshedding a bit, might be better to use #[wasmmemory] so it's more obvious to a reader.