WebAssembly にはWebAssembly.Memory
オブジェクトがあり、バイナリにはメモリ セクションがあります。これらを通じて、開発者は最小および最大のメモリ使用量に関する知識に基づいた推測を提供し、VM は少なくとも最小のメモリを割り当てます (または失敗します)。開発者は、実行時に、grow_memory
Emscripten のようなツールが内部で使用するツールを使用して、より多くの情報を要求できますmalloc
(これは に少し似ていsbrk
ます)。
asm.js の場合、 がどのように使用されるかを知ることは困難でしたArrayBuffer
。一部の 32 ビット プラットフォームでは、プロセスの断片化が頻繁に発生し、プロセスの仮想メモリに十分な連続スペースを割り当てることが難しくなりました ( は連続しているArrayBuffer
必要があります)。ブラウザ プロセスの仮想アドレス空間で、そうしないと、大きなパフォーマンス ヒットが発生する可能性があります)。256MiB を割り当てようとすると、失敗することもあります。ブラウザーがマルチプロセスでない場合、他のすべてのタブが 32 ビットの仮想アドレス空間を求めて競合するため、これは非常に困難になります。ブラウザは数年前は少しばかげていましたが、改善されましたが、32 ビットはそれほど多くはありません。
WebAssembly.Memory
WebAssembly は、特殊なタイプのによって支えられていArrayBuffer
ます。これは、WebAssembly の実装がそれに関して巧妙になる可能性があることを意味しArrayBuffer
ます。32 ビットでは、やることはあまりありません。連続したアドレス空間が不足すると、VM は多くのことを行うことができません。しかし、64 ビット プラットフォームには十分なアドレス空間があります。ブラウザーの実装では、インスタンスの作成が多すぎるのを防ぐことができWebAssembly.Memory
ます (仮想メモリの割り当てはほとんど無料ですが、完全ではありません) が、4GiB の割り当てをいくつか取得できるはずです。ブラウザはそのスペースを仮想的にのみ割り当て、必要な最小数のページに対して物理アドレスをコミットすることに注意してください。その後、使用時にのみ物理的に割り当てられますgrow_memory
. それは失敗する可能性があります (物理メモリは RAM の量とほぼ同じくらい豊富で、スワップ領域を提供または取得します) が、はるかに予測可能です。
PROT_NONE
実装は、断片化が許可されていると仮定して、32 ビット プラットフォームで同様のトリックを引き出すことができます (オーバーコミットしますが、保持し、物理的に割り当てません)。現実的には、移動するものがあまりないときにメモリを見つけるのは困難ですが、事実上および物理的には困難です。
WebAssembly は現在、ILP32 プロセスとして指定されています。ポインターは 32 ビットです。したがって、4GiB にハード制限されます。今後wasm64を追加する可能性があります。