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

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

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

* 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>

* 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 patch indices * chore: update patches --------- Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com> Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com> Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>

…ion error on riscv Compilation error: RangeError: WebAssembly.Instance(): Out of memory: Cannot allocate Wasm memory for new instance Related PR from Node: nodejs/node#52766

Original commit message: [api] add V8::CanEnableWebAssemblyTrapHandler() When the system does not have enough virtual memory for the wasm cage, installing the trap handler would cause any code allocating wasm memory to throw. Therefore it's useful for the emebdder to know when the system require is not met and in that case, skip the trap handler installation so that wasm code can at least work (even not at the maximal performance). Node.js previously has a command line option --disable-wasm-trap-handler for this, this patch would allow it to adapt automatically without requiring the use of a command line flag, which is not always under end-user's control. Refs: nodejs#52766 Refs: nodejs#60788 Refs: microsoft/vscode#251777 Bug: 40644005 Change-Id: Ie0608970daabe370db4616b875a8f098711c80e2

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 <rafael.nunu@hotmail.com>

sophoniie pushed a commit to sophoniie/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>

sophoniie pushed a commit to sophoniie/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>

bmeck pushed a commit to bmeck/node that referenced this pull request Jun 22, 2024

tools: support != in test status files

28bb654

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

bmeck pushed a commit to bmeck/node that referenced this pull request Jun 22, 2024

tools: support max_virtual_memory test configuration

f52e600

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

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…

0ce05e0

…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…

b3cd090

…andler nodejs/node#52766

emspishak mentioned this pull request Jan 14, 2025

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

Closed

Uh oh!

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

joyeecheung commented Apr 30, 2024 •

edited

Loading

joyeecheung commented May 7, 2024 •

edited

Loading