webassembly中的内存限制

Question

Web组装程序的内存分配限制政策是什么？

是否会继承当前(硬)javascript引擎内存限制？例如,可以编写需要超过几百兆内存的真实应用程序吗？

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

参见例如http://www.meshlabjs.net,MeshLab网格处理系统的浏览器版本.关于桌面应用程序,主要限制是,在基于javascript的版本中,不能加载大型3D模型以用于由浏览器的js引擎施加的分配的固有限制.

Answer 1

WebAssembly有一个WebAssembly.Memory对象,二进制文件有一个内存部分.通过这些,开发人员提供有关最小和最大内存使用量的有根据的猜测,然后VM分配至少最小(或失败).然后,开发人员可以在运行时询问更多grow_memory像Emscripten这样的工具将在哪些工具malloc(它有点类似sbrk)下使用.

对于asm.js,很难知道将如何ArrayBuffer使用,在某些32位平台上,您经常遇到进程碎片,这使得很难在进程的虚拟内存中分配足够的连续空间(ArrayBuffer 必须是连续的)在浏览器进程中的虚拟地址空间,否则你会有很大的性能.您尝试分配256MiB,有时难以失败.如果浏览器不是多进程的话,这非常困难,因为所有其他选项卡都在竞争32位的虚拟地址空间.几年前浏览器有点傻,它们变得更好,但是32位并不是很多.

WebAssembly由WebAssembly.Memory一种特殊类型的支持ArrayBuffer.这意味着WebAssembly实现可以很聪明ArrayBuffer.在32位上没有太多可做的事情:如果你用完了连续的地址空间,那么VM就无法做太多.但是在64位平台上有足够的地址空间.浏览器实现可以选择阻止您创建太多WebAssembly.Memory实例(分配虚拟内存几乎是免费的,但不是很完整),但您应该能够获得一些4GiB分配.请注意,浏览器只会虚拟地分配该空间,并提交您所需的最少页数的物理地址.之后它只会在您使用时进行物理分配grow_memory.这可能会失败(物理内存大约与RAM的数量一样多,给予或占用交换空间),但它更容易预测.

PROT_NONE假设碎片允许,实现可以在32位平台上提取类似的技巧(过度提交但保留而不是物理分配),但这取决于实现以及它如何认为这会影响ASLR.实际上,当没有太多可用的东西时,很难找到记忆,但实际上和物理上都是如此.

WebAssembly当前被指定为ILP32进程:指针是32位.因此,你很难受4GiB的限制.我们将来可能会添加wasm64.

Answer 2

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

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

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