Wasm needs a better memory management story

Hi all, after a video call with google last week, I was encouraged to raise a conversation here around issues we at Unity have with Wasm memory allocation. The short summary is that currently Wasm has grave limitations that make many applications infeasible to be _reliably_ deployed on mobile browsers. Here I stress the word reliably, since things may work on some devices for some % of users you deploy to, depending on how much memory your wasm page needs, but as your application's memory needs grow, the % of users you are able to deploy to can dramatically fall. These issues already occur when the Wasm page uses only a fraction of total RAM of the device. (e.g. at 300MB-500MB) These issues have been raised as browser issues, but the underlying theme is recognizing that the wasm spec is not robust enough for mobile deployment to customers. These troubles stem from the following limitations: 1. No way to control in a guaranteed fashion when new memory commit vs address space reserve occurs. 2. No way to uncommit used memory pages. 3. No way to shrink the allocated Wasm Memory. 4. No virtual memory support (leading applications to either expect to always be able to grow, or have to implement memory defrag solutions) 5. If Memory is Shared, then application needs to know the Maximum memory size ahead of time, or gratuitously reserve all that it can. So basically Wasm memory story is "you can only grab more memory, with no guarantee if the memory you got is a reserve or a c

Posted by juj on Feb 15, 2021, 1:14 PM

Tags

• support (Other)

Related issues

• some bike vendor told me that the biggest problem with regular to ebike conversion was that regular bike frames were not strong enough to...
• I think of this as the kiosk economy.
• What a goofy comment.
• There's lots of evidence for positive influences of Caffeine on the body (some negative as well), especially the brain.
• Compose support in WSLc
• [RFC] Roadmap to v2.0