jakobkummerow

To be clear, if bounds check elimination happens at all, it is always up to the engine. (When we previously experimented with it in V8, we found that it's surprisingly...

Here's another idea (thanks to @ecmziegler for bringing it up): - allow modules to configure a "hook" function that's invoked before trapping; this function can be used to throw an...

> If the pair of nullcheck + operate is too large It's more than that: a `br_on_null` also needs a jump target, and that place needs to contain instructions to...

> can't JS catch a Wasm trap? Yes it can, but doing so unrolls the Wasm stack all the way to its entry point (i.e. the topmost JS frame). So...

I'm generally supportive of this suggestion. In particular because it allows modules that don't need/use i31ref to avoid some i31 checks (they may be cheap, but not doing them at...

I just realized that #76 creates an interesting wrinkle here. If we have to disallow `(ref i31 extern)`, then I think we have to disallow `(ref i31 any)` too, but...

> #76 means that there would be some conversion overhead under this solution because JS numbers as anyrefs would need to be boxed to be differentiated from i31refs? That boxing...

In the meantime, I've heard specific feedback that making i31 a ref type dimension would be more efficient/useful than the current proposal for surface languages that have primitive integers: they...

I think this question (generalized to "what about the prototype?") is one aspect of the bigger question "what should the JS API for WasmGC look like?", which I consider a...

The current behavior of our prototype is that you can pass WasmGC structs/arrays to JS, where they will show up as opaque (empty-looking, as if it were `new Object()`) objects....