@@ -695,40 +695,36 @@ vm.measureMemory();
695695added:
696696- v22.2.0
697697- v20.15.0
698- -->
699-
700- By default, Node.js enables trap-handler-based WebAssembly bound
701- checks. As a result, V8 does not need to insert inline bound checks
702- in the code compiled from WebAssembly which may speed up WebAssembly
703- execution significantly, but this optimization requires allocating
704- a big virtual memory cage (currently 10GB). If the Node.js process
705- does not have access to a large enough virtual memory address space
706- due to system configurations or hardware limitations, users won't
707- be able to run any WebAssembly that involves allocation in this
708- virtual memory cage and will see an out-of-memory error.
709-
710- ``` console
711- $ ulimit -v 5000000
712- $ node -p " new WebAssembly.Memory({ initial: 10, maximum: 100 });"
713- [eval]:1
714- new WebAssembly.Memory({ initial: 10, maximum: 100 });
715- ^
716-
717- RangeError: WebAssembly.Memory(): could not allocate memory
718- at [eval]:1:1
719- at runScriptInThisContext (node:internal/vm:209:10)
720- at node:internal/process/execution:118:14
721- at [eval]-wrapper:6:24
722- at runScript (node:internal/process/execution:101:62)
723- at evalScript (node:internal/process/execution:136:3)
724- at node:internal/main/eval_string:49:3
725-
726- ```
727-
728- ` --disable-wasm-trap-handler ` disables this optimization so that
729- users can at least run WebAssembly (with less optimal performance)
730- when the virtual memory address space available to their Node.js
731- process is lower than what the V8 WebAssembly memory cage needs.
698+ changes:
699+ - version:
700+ - REPLACEME
701+ pr-url: https://github.com/nodejs/node/pull/62132
702+ description: Node.js now automatically disables the trap handler when there is not
703+ enough virtual memory available at startup to allocate one cage.
704+ -->
705+
706+ Node.js enables V8's trap-handler-based WebAssembly bound checks on 64-bit platforms,
707+ which significantly improves WebAssembly performance by eliminating the need for
708+ inline bound checks. This optimization requires allocating a large virtual memory
709+ cage per WebAssembly memory instance (currently typically 8GB for 32-bit WebAssembly memory,
710+ 16GB for 64-bit WebAssembly memory) to trap out-of-bound accesses. On most 64-bit
711+ platforms, the virtual memory address space is usually large enough (around 128TB)
712+ to accommodate typical WebAssembly usages, but if the machine has manual limits
713+ on virtual memory (e.g. through ` ulimit -v ` ), WebAssembly memory allocation is
714+ more likely to fail with ` WebAssembly.Memory(): could not allocate memory ` .
715+
716+ At startup, Node.js automatically checks whether there is enough virtual memory
717+ available to allocate at least one cage, and if not, the trap-handler optimization
718+ is automatically disabled so that WebAssembly can still run using inline
719+ bound checks (with less optimal performance). But if the application needs to create
720+ many WebAssembly memory instances and the machine still configures a relatively high
721+ limit on virtual memory, allocation of WebAssembly memory instances may still fail
722+ more quickly than expected due to the raised virtual memory usage.
723+
724+ ` --disable-wasm-trap-handler ` fully disables this optimization so that WebAssembly memory
725+ instances always use inline bound checks instead of reserving large virtual memory cages.
726+ This allows more instances to be created when the virtual memory address space available
727+ to the Node.js process is limited.
732728
733729### ` --disallow-code-generation-from-strings `
734730
0 commit comments