Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should Chrome Canary have Memory64 support? #42

Closed
juj opened this issue Sep 5, 2023 · 12 comments
Closed

Should Chrome Canary have Memory64 support? #42

juj opened this issue Sep 5, 2023 · 12 comments

Comments

@juj
Copy link

juj commented Sep 5, 2023

In issue #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:

image

image

and restart Chrome Canary, I still get

image

I wonder if I missed a step? CC @dschuff

(also tried enabling a bunch of other experimental features:

image

but of no help)

@backes
Copy link
Member

backes commented Sep 5, 2023

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
Copy link
Member

backes commented Sep 5, 2023

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
Copy link
Author

juj commented Sep 5, 2023

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?

image

@backes
Copy link
Member

backes commented Sep 5, 2023

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
Copy link
Author

juj commented Sep 5, 2023

Awesome, thanks for the speedy notes!

@juj juj closed this as completed Sep 5, 2023
juj added a commit to juj/webgl_tests that referenced this issue Sep 5, 2023
@jreininghaus
Copy link

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
Copy link
Member

backes commented Sep 19, 2023

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
Copy link

@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
Copy link

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

@juj
Copy link
Author

juj commented Sep 20, 2023

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:

image

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
Copy link
Member

backes commented Sep 20, 2023

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
Copy link
Member

backes commented Sep 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants