问webassembly中的内存限制

EN

我总结了一下上面的答案、评论和更多的谷歌搜索；有两个问题阻碍了使用WebAssembly进行需要大量内存的项目：

• 当前的WebAssembly实现遵循32位寻址空间模型，因此在wasm64耗尽之前，不可能使用超过4 4gb的内存，因此可以任意决定分配给一个页面的内存量。这(主要)是出于安全原因，因为人们喜欢将网页视为比桌面应用程序更“安全”的东西。

希望这两个问题都能得到解决。我希望浏览器能以一种明确的方式公开这些限制；就像当一个页面请求使用你的相机时得到通知一样，你应该简单地通知用户一个页面需要大量的内存，并阻止它，直到你回答。

WebAssembly有一个WebAssembly.Memory对象，二进制文件有一个memory section。通过这些，开发人员提供了关于最小和最大内存使用量的有根据的猜测，然后VM至少分配最小内存使用量(或失败)。然后，开发人员可以在运行时通过grow_memory请求更多内容，Emscripten等工具将在malloc (有点类似于sbrk)的保护下使用这些工具。

对于asm.js来说，很难知道ArrayBuffer将如何使用，而且在一些32位平台上，您经常遇到进程碎片，这使得很难在进程的虚拟内存中分配足够的连续空间( ArrayBuffer 必须在浏览器进程的虚拟地址空间中是连续的，否则会产生巨大的性能损失)。你会尝试分配256MiB，有时很难成功。如果浏览器不是多进程的，这就变得非常困难，因为所有其他选项卡都在竞争32位的虚拟地址空间。浏览器是were a bit silly a few years ago, they got better的，但是32位不是很好用。

WebAssembly是由WebAssembly.Memory支持的，它是一种特殊类型的ArrayBuffer。这意味着WebAssembly实现可以巧妙地处理该ArrayBuffer。在32位上，没有什么可做的:如果连续的地址空间用完了，那么VM就不能做很多事情。但是在64位平台上有足够的地址空间。浏览器实现可以选择防止您创建过多的WebAssembly.Memory实例(分配虚拟内存几乎是免费的，但不是完全免费)，但是您应该能够获得一些4GiB的分配。请注意，浏览器只会虚拟地分配该空间，并为您所需的最小页数提交物理地址。之后，它只会在你使用grow_memory时进行物理分配。这可能会失败(物理内存大约与RAM的数量一样丰富，交换空间也是如此)，但它更具可预测性。

一个实现可以在32位平台上使用类似的技巧(过量提交，但保留PROT_NONE，而不是物理分配)，假设碎片是允许的，但这取决于实现和它认为这如何影响ASLR。实际上，当没有太多的内存可供使用时，很难找到内存，而是虚拟的和物理的。

WebAssembly当前被指定为ILP32进程:指针为32位。因此，您被硬性限制为4GiB。我们可能会在将来添加wasm64。

相关提案(see their current stages here)：

多个内存

该提议增加了在单个Wasm模块中使用多个存储器的能力。在当前版本的Wasm中，一个应用程序已经可以创建多个内存，但只能通过将事物拆分成多个模块来实现。单个模块或函数不能同时引用多个内存。因此，不可能例如有效地将数据从一个存储器传送到另一个存储器，因为这必然涉及对每个值的不同模块的单独函数调用。

https://github.com/WebAssembly/multi-memory/blob/master/proposals/multi-memory/Overview.md

Memory64

此页面描述了一项支持大于2^32位的线性内存的建议。它没有提供新的指令，而是扩展了当前现有的指令以允许64位索引。WebAssembly线性内存对象的大小以页为单位。每页65536 (2^16)字节。在WebAssembly版本1中，一个线性内存最多可以有65536个页面，总共2^32字节(4 32)。除了此页限制之外，所有内存指令当前都使用i32类型作为内存索引。这意味着它们最多可以寻址2^32个字节。

https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md