cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler by joyeecheung · Pull Request #52766 · nodejs/node · GitHub

tools: support != in test status files

tools: support max_virtual_memory test configuration

tools: fix get_asan_state() in tools/test.py

The output of node -p process.config.variables.asan includes
a newline character so it's never exactly "1", which means
asan is always "off" for the status files. This fixes the
detection by stripping whitespaces from the output.

cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler

By default, Node.js enables trap-handler-based WebAssembly bound
checks. As a result, V8 does not need to insert inline bound checks
int the code compiled from WebAssembly which may speedup WebAssembly
execution significantly, but this optimization requires allocating
a big virtual memory cage (currently 10GB). If the Node.js process
does not have access to a large enough virtual memory address space
due to system configurations or hardware limitations, users won't
be able to run any WebAssembly that involves allocation in this
virtual memory cage and will see an out-of-memory error.

$ ulimit -v 5000000
$ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });"
[eval]:1
new WebAssembly.Memory({ initial: 10, maximum: 100 });
^

RangeError: WebAssembly.Memory(): could not allocate memory
    at [eval]:1:1
    at runScriptInThisContext (node:internal/vm:209:10)
    at node:internal/process/execution:118:14
    at [eval]-wrapper:6:24
    at runScript (node:internal/process/execution:101:62)
    at evalScript (node:internal/process/execution:136:3)
    at node:internal/main/eval_string:49:3

--disable-wasm-trap-handler disables this optimization so that
users can at least run WebAssembly (with a less optimial performance)
when the virtual memory address space available to their Node.js
process is lower than what the V8 WebAssembly memory cage needs.

Background: https://docs.google.com/document/u/3/d/1PM4Zqmlt8ac5O8UNQfY7fOsem-6MhbsB-vjFI-9XK6w/edit#heading=h.diogznvalour

Review requested:

@nodejs/startup

A more real world example of what this PR fixes:

$ ulimit -v 5000000
$ mkdir test-webpack
$ npm install --save webpack
$ node ./node_modules/.bin/webpack

[webpack-cli] RangeError: WebAssembly.Instance(): Out of memory: Cannot allocate Wasm memory for new instance
    at create (/home/ubuntu/test-webpack/node_modules/webpack/lib/util/hash/wasm-hash.js:155:4)
    at module.exports (/home/ubuntu/test-webpack/node_modules/webpack/lib/util/createHash.js:176:6)
    at /home/ubuntu/test-webpack/node_modules/webpack/lib/DefinePlugin.js:351:22
    at _next31 (eval at create (/home/ubuntu/test-webpack/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:42:1)
    at _next9 (eval at create (/home/ubuntu/test-webpack/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:97:1)
    at Hook.eval [as call] (eval at create (/home/ubuntu/test-webpack/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:119:1)
    at Hook.CALL_DELEGATE [as _call] (/home/ubuntu/test-webpack/node_modules/tapable/lib/Hook.js:14:14)
    at Compiler.newCompilation (/home/ubuntu/test-webpack/node_modules/webpack/lib/Compiler.js:1255:26)
    at /home/ubuntu/test-webpack/node_modules/webpack/lib/Compiler.js:1299:29
    at Hook.eval [as callAsync] (eval at create (/home/ubuntu/test-webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)

(This happens because Webpack uses a wasm implementation of md4)

CI: https://ci.nodejs.org/job/node-test-pull-request/58823/

CI: https://ci.nodejs.org/job/node-test-pull-request/58840/

CI: https://ci.nodejs.org/job/node-test-pull-request/58871/

The output of `node -p process.config.variables.asan` includes a newline character so it's never exactly "1", which means asan is always "off" for the status files. This fixes the detection by stripping whitespaces from the output.

…andler By default, Node.js enables trap-handler-based WebAssembly bound checks. As a result, V8 does not need to insert inline bound checks int the code compiled from WebAssembly which may speedup WebAssembly execution significantly, but this optimization requires allocating a big virtual memory cage (currently 10GB). If the Node.js process does not have access to a large enough virtual memory address space due to system configurations or hardware limitations, users won't be able to run any WebAssembly that involves allocation in this virtual memory cage and will see an out-of-memory error. ```console $ ulimit -v 5000000 $ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });" [eval]:1 new WebAssembly.Memory({ initial: 10, maximum: 100 }); ^ RangeError: WebAssembly.Memory(): could not allocate memory at [eval]:1:1 at runScriptInThisContext (node:internal/vm:209:10) at node:internal/process/execution:118:14 at [eval]-wrapper:6:24 at runScript (node:internal/process/execution:101:62) at evalScript (node:internal/process/execution:136:3) at node:internal/main/eval_string:49:3 ``` `--disable-wasm-trap-handler` disables this optimization so that users can at least run WebAssembly (with a less optimial performance) when the virtual memory address space available to their Node.js process is lower than what the V8 WebAssembly memory cage needs.

CI: https://ci.nodejs.org/job/node-test-pull-request/58875/

CI: https://ci.nodejs.org/job/node-test-pull-request/58876/

CI: https://ci.nodejs.org/job/node-test-pull-request/58908/

CI: https://ci.nodejs.org/job/node-test-pull-request/58997/

CI: https://ci.nodejs.org/job/node-test-pull-request/59000/

cc @nodejs/cpp-reviewers @nodejs/build

…-trap-handler

Added YAML and manpage entries, thanks for the reminder.

As for stability index, it seems unnecessary for a flag that serves as an escape hatch in a special environment - we don't usually add stability index to this kind of flags, either, and there is no clear criteria when this should be considered stable or how it could change over time - I expect the flag to just keep working as it is. If we must assign an index, I think it's fine to just mark it stable. But I'd prefer to just leave it out like most other optional CLI flags.

LGTM

CI: https://ci.nodejs.org/job/node-test-pull-request/59069/

CI: https://ci.nodejs.org/job/node-test-pull-request/59073/

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

The output of `node -p process.config.variables.asan` includes a newline character so it's never exactly "1", which means asan is always "off" for the status files. This fixes the detection by stripping whitespaces from the output. PR-URL: #52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

By default, Node.js enables trap-handler-based WebAssembly bound checks. As a result, V8 does not need to insert inline bound checks int the code compiled from WebAssembly which may speedup WebAssembly execution significantly, but this optimization requires allocating a big virtual memory cage (currently 10GB). If the Node.js process does not have access to a large enough virtual memory address space due to system configurations or hardware limitations, users won't be able to run any WebAssembly that involves allocation in this virtual memory cage and will see an out-of-memory error. ```console $ ulimit -v 5000000 $ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });" [eval]:1 new WebAssembly.Memory({ initial: 10, maximum: 100 }); ^ RangeError: WebAssembly.Memory(): could not allocate memory at [eval]:1:1 at runScriptInThisContext (node:internal/vm:209:10) at node:internal/process/execution:118:14 at [eval]-wrapper:6:24 at runScript (node:internal/process/execution:101:62) at evalScript (node:internal/process/execution:136:3) at node:internal/main/eval_string:49:3 ``` `--disable-wasm-trap-handler` disables this optimization so that users can at least run WebAssembly (with a less optimial performance) when the virtual memory address space available to their Node.js process is lower than what the V8 WebAssembly memory cage needs. PR-URL: #52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Notable changes: doc: * add pimterry to collaborators (Tim Perry) #52874 inspector: * (SEMVER-MINOR) introduce the `--inspect-wait` flag (Kohei Ueno) #52734 test_runner: * (SEMVER-MINOR) support test plans (Colin Ihrig) #52860 tools: * (SEMVER-MINOR) fix get_asan_state() in tools/test.py (Joyee Cheung) #52766 * (SEMVER-MINOR) support max_virtual_memory test configuration (Joyee Cheung) #52766 * (SEMVER-MINOR) support != in test status files (Joyee Cheung) #52766 zlib: * (SEMVER-MINOR) expose zlib.crc32() (Joyee Cheung) #52692 PR-URL: #53486

By default, Node.js enables trap-handler-based WebAssembly bound checks. As a result, V8 does not need to insert inline bound checks int the code compiled from WebAssembly which may speedup WebAssembly execution significantly, but this optimization requires allocating a big virtual memory cage (currently 10GB). If the Node.js process does not have access to a large enough virtual memory address space due to system configurations or hardware limitations, users won't be able to run any WebAssembly that involves allocation in this virtual memory cage and will see an out-of-memory error. ```console $ ulimit -v 5000000 $ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });" [eval]:1 new WebAssembly.Memory({ initial: 10, maximum: 100 }); ^ RangeError: WebAssembly.Memory(): could not allocate memory at [eval]:1:1 at runScriptInThisContext (node:internal/vm:209:10) at node:internal/process/execution:118:14 at [eval]-wrapper:6:24 at runScript (node:internal/process/execution:101:62) at evalScript (node:internal/process/execution:136:3) at node:internal/main/eval_string:49:3 ``` `--disable-wasm-trap-handler` disables this optimization so that users can at least run WebAssembly (with a less optimial performance) when the virtual memory address space available to their Node.js process is lower than what the V8 WebAssembly memory cage needs. PR-URL: #52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Notable changes: doc: * add pimterry to collaborators (Tim Perry) #52874 inspector: * (SEMVER-MINOR) introduce the `--inspect-wait` flag (Kohei Ueno) #52734 test_runner: * (SEMVER-MINOR) support test plans (Colin Ihrig) #52860 tools: * (SEMVER-MINOR) fix get_asan_state() in tools/test.py (Joyee Cheung) #52766 * (SEMVER-MINOR) support max_virtual_memory test configuration (Joyee Cheung) #52766 * (SEMVER-MINOR) support != in test status files (Joyee Cheung) #52766 zlib: * (SEMVER-MINOR) expose zlib.crc32() (Joyee Cheung) #52692 PR-URL: #53486

PR-URL: nodejs#52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

The output of `node -p process.config.variables.asan` includes a newline character so it's never exactly "1", which means asan is always "off" for the status files. This fixes the detection by stripping whitespaces from the output. PR-URL: nodejs#52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

By default, Node.js enables trap-handler-based WebAssembly bound checks. As a result, V8 does not need to insert inline bound checks int the code compiled from WebAssembly which may speedup WebAssembly execution significantly, but this optimization requires allocating a big virtual memory cage (currently 10GB). If the Node.js process does not have access to a large enough virtual memory address space due to system configurations or hardware limitations, users won't be able to run any WebAssembly that involves allocation in this virtual memory cage and will see an out-of-memory error. ```console $ ulimit -v 5000000 $ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });" [eval]:1 new WebAssembly.Memory({ initial: 10, maximum: 100 }); ^ RangeError: WebAssembly.Memory(): could not allocate memory at [eval]:1:1 at runScriptInThisContext (node:internal/vm:209:10) at node:internal/process/execution:118:14 at [eval]-wrapper:6:24 at runScript (node:internal/process/execution:101:62) at evalScript (node:internal/process/execution:136:3) at node:internal/main/eval_string:49:3 ``` `--disable-wasm-trap-handler` disables this optimization so that users can at least run WebAssembly (with a less optimial performance) when the virtual memory address space available to their Node.js process is lower than what the V8 WebAssembly memory cage needs. PR-URL: nodejs#52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Notable changes: cli: * (SEMVER-MINOR) allow running wasm in limited vmem with --disable-wasm-trap-handler (Joyee Cheung) nodejs#52766 doc: * add pimterry to collaborators (Tim Perry) nodejs#52874 fs: * (SEMVER-MINOR) allow 'withFileTypes' to be used with globs (Aviv Keller) nodejs#52837 inspector: * (SEMVER-MINOR) introduce the `--inspect-wait` flag (Kohei Ueno) nodejs#52734 lib,src: * remove --experimental-policy (Rafael Gonzaga) nodejs#52583 perf_hooks: * (SEMVER-MINOR) add `deliveryType` and `responseStatus` fields (Matthew Aitken) nodejs#51589 test_runner: * (SEMVER-MINOR) support test plans (Colin Ihrig) nodejs#52860 zlib: * (SEMVER-MINOR) expose zlib.crc32() (Joyee Cheung) nodejs#52692 PR-URL: nodejs#52971

Notable changes: doc: * add pimterry to collaborators (Tim Perry) nodejs#52874 inspector: * (SEMVER-MINOR) introduce the `--inspect-wait` flag (Kohei Ueno) nodejs#52734 test_runner: * (SEMVER-MINOR) support test plans (Colin Ihrig) nodejs#52860 tools: * (SEMVER-MINOR) fix get_asan_state() in tools/test.py (Joyee Cheung) nodejs#52766 * (SEMVER-MINOR) support max_virtual_memory test configuration (Joyee Cheung) nodejs#52766 * (SEMVER-MINOR) support != in test status files (Joyee Cheung) nodejs#52766 zlib: * (SEMVER-MINOR) expose zlib.crc32() (Joyee Cheung) nodejs#52692 PR-URL: nodejs#53486

…andler nodejs/node#52766

* chore: bump node in DEPS to v20.15.0 * doc: Add OpenSSL errors to API docs nodejs/node#34213 * test: crypto-rsa-dsa testing for dynamic openssl nodejs/node#52781 * src: allow preventing debug signal handler start nodejs/node#46681 * cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler nodejs/node#52766 * chore: fixup indices --------- Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com> Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>

…andler nodejs/node#52766

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. labels Apr 30, 2024

VoltrexKeyva reviewed May 1, 2024

View reviewed changes

Comment thread doc/api/cli.md Outdated

joyeecheung force-pushed the wasm-trap-disable branch from 1906f18 to 61b7375 Compare May 2, 2024 16:43

joyeecheung added 4 commits May 2, 2024 23:31

tools: support != in test status files

9d70355

tools: support max_virtual_memory test configuration

7857c4b

tools: fix get_asan_state() in tools/test.py

3d8aa53

The output of `node -p process.config.variables.asan` includes a newline character so it's never exactly "1", which means asan is always "off" for the status files. This fixes the detection by stripping whitespaces from the output.

joyeecheung force-pushed the wasm-trap-disable branch from 61b7375 to a087263 Compare May 2, 2024 21:34

RafaelGSS reviewed May 7, 2024

View reviewed changes

Comment thread doc/api/cli.md

fixup! cli: allow running wasm in limited vmemory with --disable-wasm…

958ef09

…-trap-handler

RafaelGSS approved these changes May 8, 2024

View reviewed changes

joyeecheung added the request-ci Add this label to start a Jenkins CI on a PR. label May 9, 2024

github-actions Bot removed the request-ci Add this label to start a Jenkins CI on a PR. label May 9, 2024

joyeecheung added a commit that referenced this pull request May 10, 2024

tools: support != in test status files

a701e42

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

marco-ippolito pushed a commit that referenced this pull request Jun 17, 2024

tools: support max_virtual_memory test configuration

e98c305

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

soophoo pushed a commit to soophoo/node that referenced this pull request Jun 20, 2024

tools: support != in test status files

656c374

PR-URL: nodejs#52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

soophoo pushed a commit to soophoo/node that referenced this pull request Jun 20, 2024

tools: support max_virtual_memory test configuration

d53154b

PR-URL: nodejs#52766 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

codebytere added a commit to electron/electron that referenced this pull request Jun 24, 2024

cli: allow running wasm in limited vmemory with --disable-wasm-trap-h…

c889290

…andler nodejs/node#52766

codebytere added a commit to electron/electron that referenced this pull request Jun 24, 2024

cli: allow running wasm in limited vmemory with --disable-wasm-trap-h…

09f8eae

…andler nodejs/node#52766

codebytere added a commit to electron/electron that referenced this pull request Jun 24, 2024

cli: allow running wasm in limited vmemory with --disable-wasm-trap-h…

4793c1f

…andler nodejs/node#52766

codebytere added a commit to electron/electron that referenced this pull request Jun 24, 2024

cli: allow running wasm in limited vmemory with --disable-wasm-trap-h…

740772b

…andler nodejs/node#52766

codebytere added a commit to electron/electron that referenced this pull request Jun 24, 2024

cli: allow running wasm in limited vmemory with --disable-wasm-trap-h…

c99caf8

…andler nodejs/node#52766

codebytere added a commit to electron/electron that referenced this pull request Jun 27, 2024

cli: allow running wasm in limited vmemory with --disable-wasm-trap-h…

74b3483

…andler nodejs/node#52766

codebytere added a commit to electron/electron that referenced this pull request Jun 27, 2024

cli: allow running wasm in limited vmemory with --disable-wasm-trap-h…

d126bfd

…andler nodejs/node#52766

emspishak mentioned this pull request Jan 14, 2025

Wasm doesn't work in limited virtual memory situations #56596

Closed

cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler by joyeecheung · Pull Request #52766 · nodejs/node · GitHub

Uh oh!

Uh oh!

cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler - #52766

cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler#52766joyeecheung wants to merge 5 commits intonodejs:mainnodejs/node:mainfrom joyeecheung:wasm-trap-disablejoyeecheung/node:wasm-trap-disableCopy head branch name to clipboard

Conversation

joyeecheung commented Apr 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

tools: support != in test status files

tools: support max_virtual_memory test configuration

tools: fix get_asan_state() in tools/test.py

cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler

Uh oh!

nodejs-github-bot commented Apr 30, 2024

Uh oh!

joyeecheung commented Apr 30, 2024

Uh oh!

nodejs-github-bot commented Apr 30, 2024

Uh oh!

Uh oh!

nodejs-github-bot commented May 1, 2024

Uh oh!

nodejs-github-bot commented May 2, 2024

Uh oh!

nodejs-github-bot commented May 2, 2024

Uh oh!

nodejs-github-bot commented May 2, 2024

Uh oh!

nodejs-github-bot commented May 3, 2024

Uh oh!

nodejs-github-bot commented May 7, 2024

Uh oh!

nodejs-github-bot commented May 7, 2024

Uh oh!

joyeecheung commented May 7, 2024

Uh oh!

Uh oh!

joyeecheung commented May 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RafaelGSS left a comment

Choose a reason for hiding this comment

Uh oh!

nodejs-github-bot commented May 9, 2024

Uh oh!

nodejs-github-bot commented May 10, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

cli: allow running wasm in limited vmemory with --disable-wasm-trap-handler#52766
joyeecheung wants to merge 5 commits into
nodejs:mainfrom
joyeecheung:wasm-trap-disable

joyeecheung commented Apr 30, 2024 •
edited
Loading

joyeecheung commented May 7, 2024 •
edited
Loading