Should Chrome Canary have Memory64 support?

[juj]

In issue https://github.com/WebAssembly/memory64/issues/36 , @backes mentioned that

Memory64 is currently "staged" in V8, meaning it is enabled if you enable "Experimental WebAssembly" in the chrome flags: chrome://flags/#enable-experimental-webassembly-features

but when I try:

and restart Chrome Canary, I still get

I wonder if I missed a step? CC @dschuff

(also tried enabling a bunch of other experimental features:

but of no help)

[backes]

Thanks for reporting this. Indeed the JS API is not fully complete yet, in fact the respective PR (#32) in this repo was only merged two weeks ago, and there is a pending change to switch from u32/u64 to i32/i64 (#41).

Once that's all settled and we have spec tests for this, I'll fix the JS API implementation in V8 to allow for bigger initial and maximum values for 64-bit memories.

Until then, you can create larger memories via a declared memory in a Wasm module.

[backes]

I just tried in a Canary version, and indeed if you include index: 'u64', then you can already create bigger memories. But as noted, this will change soon to i64, so don't rely on that yet.

[juj]

Thanks! I can see that works (I am just locally testing out stuff).

Should it be possible (currently, or in the future) to create a single view that is equal to the length of the created memory?

[backes]

That's a known limitation in V8 and is tracked via https://crbug.com/v8/4153. The work is currently stalled a bit but we plan to pick it up once we have free resources.

[juj]

Awesome, thanks for the speedy notes!

[jreininghaus]

Once that's all settled and we have spec tests for this, I'll fix the JS API implementation in V8 to allow for bigger initial and maximum values for 64-bit memories.

@backes, does this mean that we are going to be able to specify to memory limit (i.e. something larger than the current 16 GB) in the UI somewhere going forward or am I misunderstanding your comment?

In any case, having more than 16 GB available (at least as an opt-in) would be quite useful for our application.

[backes]

Once that's all settled and we have spec tests for this, I'll fix the JS API implementation in V8 to allow for bigger initial and maximum values for 64-bit memories.

@backes, does this mean that we are going to be able to specify to memory limit (i.e. something larger than the current 16 GB) in the UI somewhere going forward or am I misunderstanding your comment?

No, this is not what I meant. I meant that you can specify up to 16GB of memory if you pass the right flag (index: 'i64') on the WebAssembly.Memory constructor.

In any case, having more than 16 GB available (at least as an opt-in) would be quite useful for our application.

Please open a bug in the V8 bug tracker (https://crbug.com/v8/new) and describe your use case. We could bump the limit to 32GB without much hassle, going further up is difficult because of a limit imposed by the V8 sandbox.

[jreininghaus]

@backes , thanks a lot for the quick reply. I am going to create a ticket as you recommended. Having 32 GB available (instead of 16 GB) would already be a big help and solve 99% of the use cases I imagine.

[jreininghaus]

Here is the V8 ticket: https://bugs.chromium.org/p/v8/issues/detail?id=14323

[juj]

I wrote a test for >4GB memories for WebGL conformance suite a week or so ago. Naturally it would fail in WebGL since it doesn't yet do >4GB views, but today I find that in Chrome Canary the test starts to fail even earlier, when trying to create a view to the >4GB memory:

I think this did work a week ago? Might this be a regression, or am I confused and >4GB views never worked so far?

[backes]

I think this never worked in V8. This is tracked as issue 4153, and it should be fixed within the next days: https://crrev.com/c/4872536

[backes]

I think this never worked in V8. This is tracked as issue 4153, and it should be fixed within the next days: https://crrev.com/c/4872536

FYI, this landed now. Bigger TypedArrays should work since Chromium version 119.0.6030.1.