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

joyeecheung · 2024-04-30T21:02:30Z

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

nodejs-github-bot · 2024-04-30T21:02:35Z

Review requested:

@nodejs/startup

joyeecheung · 2024-04-30T21:07:42Z

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)

nodejs-github-bot · 2024-04-30T21:10:19Z

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

doc/api/cli.md

nodejs-github-bot · 2024-05-01T16:53:56Z

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

nodejs-github-bot · 2024-05-02T16:45:26Z

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.

nodejs-github-bot · 2024-05-02T21:36:35Z

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

nodejs-github-bot · 2024-05-02T21:36:35Z

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

nodejs-github-bot · 2024-05-03T20:30:38Z

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

nodejs-github-bot · 2024-05-07T00:21:57Z

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

nodejs-github-bot · 2024-05-07T02:35:56Z

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

joyeecheung · 2024-05-07T05:25:59Z

cc @nodejs/cpp-reviewers @nodejs/build

doc/api/cli.md

…-trap-handler

joyeecheung · 2024-05-07T21:47:06Z

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.

RafaelGSS

LGTM

nodejs-github-bot · 2024-05-09T23:29:30Z

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

nodejs-github-bot · 2024-05-10T06:33:59Z

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

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <[email protected]>

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 <[email protected]>

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 <[email protected]>

joyeecheung · 2024-05-10T09:15:02Z

Landed in e03529e...77fabfb

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <[email protected]>

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 <[email protected]>

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 <[email protected]>

targos · 2024-05-13T12:39:52Z

This PR adds a feature so it should be labeled semver-minor PRs that contain new features and should be released in the next minor version. (this is not supposed to be done by releasers).

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

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

doc/api/cli.md Outdated Show resolved Hide resolved

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

doc/api/cli.md Show resolved Hide resolved

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 <[email protected]>

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

tools: support max_virtual_memory test configuration

4da1d1a

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <[email protected]>

joyeecheung closed this May 10, 2024

targos pushed a commit that referenced this pull request May 11, 2024

tools: support != in test status files

1600bda

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <[email protected]>

targos pushed a commit that referenced this pull request May 11, 2024

tools: support max_virtual_memory test configuration

6e71acc

PR-URL: #52766 Reviewed-By: Rafael Gonzaga <[email protected]>

targos added the semver-minor PRs that contain new features and should be released in the next minor version. label May 13, 2024

targos mentioned this pull request May 13, 2024

v22.2.0 release proposal #52971

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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 #52766

joyeecheung commented Apr 30, 2024 •

edited

nodejs-github-bot commented Apr 30, 2024

joyeecheung commented Apr 30, 2024

nodejs-github-bot commented Apr 30, 2024

nodejs-github-bot commented May 1, 2024

nodejs-github-bot commented May 2, 2024

nodejs-github-bot commented May 2, 2024

nodejs-github-bot commented May 2, 2024

nodejs-github-bot commented May 3, 2024

nodejs-github-bot commented May 7, 2024

nodejs-github-bot commented May 7, 2024

joyeecheung commented May 7, 2024

joyeecheung commented May 7, 2024 •

edited

RafaelGSS left a comment

nodejs-github-bot commented May 9, 2024

nodejs-github-bot commented May 10, 2024

joyeecheung commented May 10, 2024

targos commented May 13, 2024

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 #52766

Conversation

joyeecheung commented Apr 30, 2024 • edited

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

nodejs-github-bot commented Apr 30, 2024

joyeecheung commented Apr 30, 2024

nodejs-github-bot commented Apr 30, 2024

nodejs-github-bot commented May 1, 2024

nodejs-github-bot commented May 2, 2024

nodejs-github-bot commented May 2, 2024

nodejs-github-bot commented May 2, 2024

nodejs-github-bot commented May 3, 2024

nodejs-github-bot commented May 7, 2024

nodejs-github-bot commented May 7, 2024

joyeecheung commented May 7, 2024

joyeecheung commented May 7, 2024 • edited

RafaelGSS left a comment

Choose a reason for hiding this comment

nodejs-github-bot commented May 9, 2024

nodejs-github-bot commented May 10, 2024

joyeecheung commented May 10, 2024

targos commented May 13, 2024

joyeecheung commented Apr 30, 2024 •

edited

joyeecheung commented May 7, 2024 •

edited