Web site memory limits

Question

What will be the memory allocation restriction policy for web build programs?

Will the current (hard) memory limit of the javascript engine be inherited? For instance. Will it be possible to write real applications that require more than several hundred megabytes of memory?

Current browser policies in memory allocation in javascript create severe restrictions on what can actually be done in the browser. Speed ​​is no longer a problem with compiling emscripten / asm.js and jit, but memory limitations make it difficult or impossible to create any serious application in the browser.

See, for example, http://www.meshlabjs.net , the version of the MeshLab browser to run in the browser. As for the desktop application, the main limitation is that in the javascript-based version, large 3D models cannot be loaded for internal restrictions on the distribution imposed by the js browser engine.

Answer 1

I summarize the above answers, comments and a bit more about googling; There are two problems that prevent the use of WebAssembly for using projects that require a significant amount of memory:

• current WebAssembly implementations follow the 32-bit address space model, so there is no hope of using more than 4 GB of memory before wasm64 .
• browsers arbitrarily determine how much memory is indicated on the page. This is (mainly) for security reasons, because people like to think on web pages as something more "secure" than desktop applications.

We hope that both problems can be resolved. I hope browsers explicitly disclose these limitations; just like when requesting a page to use the camera, you just need to notify the user that the page wants a ton of memory and lock it until you respond.

Answer 2

WebAssembly has a WebAssembly.Memory object, and the binary has a memory section . Thanks to this, the developer gives reasonable guesses about the minimum and maximum memory usage, then the VM allocates at least a minimum (or failure). Then the developer can at runtime request more grow_memory , which tools, such as Emscripten, will be used under the malloc hood (this is somewhat similar to sbrk ).

It was difficult for asm.js to understand how ArrayBuffer will be used, and on some 32-bit platforms you often faced fragmentation of the process, which made it difficult to allocate enough continuous space in the "virtual memory ( ArrayBuffer should be adjacent to the virtual address space of the browser" process, otherwise you will have a huge perfect). You will try to allocate 256MiB, and sometimes unsuccessfully. It was extremely difficult if the browser was not a multiprocessor, because all the other tabs compete for 32 bits of the virtual address space. Browsers were a little stupid a few years ago, they have improved , but 32 bits are not much to get around.

WebAssembly is supported by WebAssembly.Memory , which is a special type of ArrayBuffer . This means that the WebAssembly implementation may be smart with respect to ArrayBuffer . At the 32-bit level, you have nothing to do: if you finish the adjacent address space, then the VM will not be able to do much. But on 64-bit platforms there is a lot of address space. A browser implementation may prevent you from creating too many instances of WebAssembly.Memory (virtual memory allocation is almost free, but not quite), but you should be able to get multiple 4GiB allocations. Please note that the browser will simply allocate this space practically and fix the physical addresses for the minimum number of pages that you think you need. Subsequently, it will only be physically allocated when using grow_memory . This may fail (physical memory is about the same as the amount of RAM that gives or takes up swap space), but it is much more predictable.

An implementation can bring out a similar trick on 32-bit platforms (over-commit, but retain PROT_NONE and not physically distribute), assuming fragmentation allows, but as for the implementation, and how it thinks it affects ASLR. It’s really hard to find a memory when you’re not walking that much, but practically and physically.

WebAssembly is currently defined as an ILP32 process: pointers are 32 bits. Therefore, it is difficult for you to limit 4GiB. We can add wasm64 in the future.