wasm64: support memory larger than 16 GB

[jspanchu]

I asked this question at emscripten-core/emscripten#23966 and was told it's a limitation imposed by the spec.

In wasm64, the spec caps the maximum memory to 16 GB in https://github.com/WebAssembly/memory64/blob/9003cd5e24e53b84cd9027ea3dd7ae57159a6db1/document/js-api/index.bs#L1785.

Could we please get wasm64 to support as much memory available from the host machine's RAM? I'd also like to understand reasons behind the 16GB limit when technically 64-bit integers can be used to index memories much larger than 16GB.

@sbc100

[titzer]

Note this is a standard limit imposed by the JS API, it's not necessarily the same limit in other embedding contexts. Any limit is subject to future revision, but if your use case is outside of the web, then an engine could provide more memory.

[jspanchu]

Note this is a standard limit imposed by the JS API

Is this documented somewhere?

[titzer]

Yes, the link you provided was into the JS-API documentation, which is technically separate from the core Wasm specification.

[jspanchu]

Ah, I see. Is this due to a limitation of JS execution engines like browsers/node? Where do I lobby to increase the JS-API limit?

[sbc100]

I believe you have found the correct forum. The JS-API spec is maintained alongside the wasm core spec here: https://github.com/WebAssembly/spec/blob/main/document/js-api/index.bs.

[duolanda]

I encountered the same issue as you did, and I discovered that the 16GB memory limit is also documented in the source code of the V8 engine. : src/wasm/wasm-limits.h - v8/v8 - Git at Google
Does this imply that increasing the memory limit is difficult unless the V8 engine is updated? Or is it possible for browsers using the V8 engine to allocate more than 16GB of memory now?

[eqrion]

This is the right place to ask for the JS-API limit to be increased. SpiderMonkey/Firefox shares the same restriction (taken from the JS-API) that you cannot ever grow a wasm memory above 16GiB.

In practice it's unlikely that you'll be able to even grow to 16GiB. On 32-bit systems we have a much lower limit, and 16GiB of memory is relatively rare in the Firefox user base. Any web experience that requires more than 16GiB is unlikely to run for most users.

I'm open to raising the limit someday, but I'm skeptical it's going be used that often. It also really makes browsers tests of large memories difficult to do, as we've noticed that our test runners get OOM killed frequently once they start using that much memory.

[kripken]

@eqrion

Any web experience that requires more than 16GiB is unlikely to run for most users. I'm open to raising the limit someday, but I'm skeptical it's going be used that often.

I definitely agree this would be used by few people, and rarely.

But as I see it, the request here is for that small use case. That is, this isn't for something like a game that we want everyone to run. It is for something like a graphical editor, and the rare users of it that have huge data files that actually need more than 16 GB of RAM.

[eqrion]

But as I see it, the request here is for that small use case. That is, this isn't for something like a game that we want everyone to run. It is for something like a graphical editor, and the rare users of it that have huge data files that actually need more than 16 GB of RAM.

That's fair enough. I guess what I was trying to say is that it's not as simple as just raising the limit, because it complicates our test infrastructure. We had a hard time getting 16GiB tests working reliably. So that needs to be balanced with the number of users.

But I'm open to doing it someday.

[bvisness]

In my opinion it would be foolish to continue to increase the memory size limit without also adding new APIs that give you better control over memory. We still don't even have a way to release memory back to the operating system when you're done with it, for example.

Also, my impression is that those who want large address spaces actually want to do more sophisticated things with that address space, e.g. memory mapping or reserve/commit for their allocators. I would be hesitant to increase the limit, only to find out that it still lacks critical features for memory-hungry applications.

[tzarebczan]

This feels like the age old question when it comes to wasm in browser. Can you use a different engine?

Is anyone actually running something with >16GB ram? If so, how?

You mention it's "...because it complicates our test infrastructure. We had a hard time getting 16GiB tests working reliably." - Can you elaborate?

also +1 to the last comment about additional APIs, e.g. release mem. Where do we start for that?

edit: just read sqlite/sqlite-wasm#119 too - will take a closer look.

[bvisness]

The main thing to understand is that when you instantiate a 16GB WASM memory, you are asking the operating system to not just reserve, but commit 16GB of read/write contiguous memory. It is like a 16GB call to malloc. On many, many devices, such a call will simply fail.

I know that people think they want to just have WASM use all the memory on their machine, somehow. But until such a time as WASM gets a more advanced memory model, it probably doesn't make sense to raise the limit in browsers.

If you are interested in what those more advanced memory APIs might be, I encourage you to check out the memory control proposal and the discussions there.

[tzarebczan]

Yeah, totally understood. Didn't know so much work went into the memory management discussion, thank you.

There's just some use cases developers have where they know they need it and have the memory available. Definitely not a default, but a dangerously flagged override.