WebAssembly 中的内存限制

Question

WebAssembly 程序的内存分配限制政策是什么？

是否会继承当前的(硬)javascript 引擎内存限制？例如。是否可以编写需要数百兆内存的实际应用程序？

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

参见示例 http://www.meshlabjs.net , MeshLab 网格处理系统的浏览器运行版本。对于桌面应用程序，主要限制是，在基于 javascript 的版本中，由于浏览器的 js 引擎对分配的内在限制，无法加载大型 3D 模型。

Answer 1

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 future 。