Memory webassembly中的内存限制

webassembly程序的内存分配限制策略是什么

当前（硬）javascript引擎内存限制是否会被继承？ 例如，是否有可能编写需要几百兆以上内存的实际应用程序

当前关于javascript内存分配的浏览器策略对浏览器中实际可行的内容提出了硬约束。 速度不再是emscripten/asm.js和jit编译的问题，但是内存限制使得在浏览器中构建任何严肃的应用程序变得困难或不可能

例如，请参见MeshLab网格处理系统的运行浏览器版本。对于桌面应用程序，主要限制是，在基于javascript的版本中，由于浏览器的js引擎对分配施加的固有限制，无法加载大型3D模型

WebAssembly有一个对象，二进制文件有一个。通过这些，开发人员提供关于最小和最大内存使用量的有根据的猜测，然后VM至少分配最小内存（或失败）。然后，开发人员可以在运行时要求更多的工具，比如Emscripten，在

malloc

的保护下使用这些工具（这有点类似于

sbrk

）

对于asm.js，很难知道如何使用

ArrayBuffer

，在某些32位平台上，您经常遇到进程碎片，这使得很难在进程的虚拟内存中分配足够的连续空间（在浏览器进程的虚拟地址空间中，

ArrayBuffer

必须是连续的，否则会产生巨大的性能影响）。您可能会尝试分配256MB，但有时会出现硬失败。如果浏览器不是多进程的，这会变得非常困难，因为所有其他选项卡都在争夺32位的虚拟地址空间。浏览器，但32位并不多

WebAssembly由

WebAssembly.Memory

支持，它是一种特殊类型的

ArrayBuffer

。这意味着WebAssembly实现可以巧妙地处理

ArrayBuffer

。在32位上没什么可做的：如果连续地址空间用完，虚拟机就做不了什么。但在64位平台上，没有足够的内存地址空间不足。浏览器实现可以选择防止您创建太多

WebAssembly.Memory

实例（分配虚拟内存几乎是免费的，但不是完全免费的），但您应该能够获得一些4GiB分配。请注意，浏览器将仅虚拟分配该空间，并提交您所需的最小页数的物理地址。之后，它将仅在您使用

grow\u memory

时进行物理分配。这可能会失败（物理内存大约和RAM的数量一样丰富，交换空间的大小也一样），但它的可预测性要高得多

一个实现可以在32位平台上使用类似的技巧（过度提交，但保持

PROT_NONE

且不进行物理分配），假设碎片允许，但这取决于实现，以及它认为这会如何影响ASLR。实际上，当没有太多东西可供使用时，很难找到内存，但实际上是虚拟的和物理的

---

WebAssembly目前被指定为一个ILP32进程：指针是32位的。因此，您很难被限制为4GiB。我们可能会在将来添加它。

我总结了一点以上的答案、注释和谷歌搜索的更多内容；有两个问题阻碍了将WebAssembly用于需要大量amo的项目内存大小：

• 当前的WebAssembly实现遵循32位寻址空间模型，因此在wasm64退出之前，不可能使用超过4gb的内存（）
• 浏览器任意决定给一个页面的内存量。这（主要）是出于安全原因，因为人们喜欢认为网页比桌面应用程序更“安全”

我希望这两个问题都能得到解决。我希望浏览器能以一种明确的方式暴露这些限制；就像当一个页面请求使用您的相机时收到通知一样，您只需通知用户某个页面需要大量内存，并将其阻止，直到您回答。

相关建议（）：

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

记忆64 本页介绍支持大于2^32位的线性内存的建议。它不提供新指令，而是扩展当前现有指令以允许64位索引

WebAssembly线性内存对象的大小以页为单位。每个页的大小为65536（2^16）字节。在WebAssembly版本1中，线性内存最多可以有65536页，总计为2^32字节（4 GB）。除此页面限制外，所有内存指令当前都使用i32类型作为内存索引。这意味着它们最多可以寻址2^32字节

---

实际上，我认为

WebAssembly.Memory

API与此无关。事实上，Wasm模块可以定义自己的内存，而asm.js总是从js导入内存，因此引擎无法区分用例。也就是说，js引擎中的内存限制主要不是由硬件造成的或者解决空间限制，但防止网页使用OOM杀死机器，这在某些操作系统上很容易。这也适用于Wasm。我不确定我们是否已经解决了这方面的任何问题。我们给出了什么