Uh oh!
There was an error while loading. Please reload this page.
[WIP] only install WASM trap handler when there's enough virtual memory - #60788
Closed
joyeecheung wants to merge 2 commits into
Closed
[WIP] only install WASM trap handler when there's enough virtual memory#60788joyeecheung wants to merge 2 commits into
joyeecheung wants to merge 2 commits into
Conversation
nodejs-github-bot
commented
Nov 20, 2025
Collaborator
Review requested:
|
joyeecheung
marked this pull request as draft
November 20, 2025 06:58
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@## main #60788 +/- ##
==========================================
+ Coverage 88.04% 88.53% +0.49%
==========================================
Files 703 703 Lines 208260 208260 Branches 40068 40154 +86 ==========================================
+ Hits 183360 184390 +1030 + Misses 16840 15885 -955 + Partials 8060 7985 -75 🚀 New features to boost your workflow:
|
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
joyeecheungforce-pushed
the
wasm-handler
branch
from
December 10, 2025 17:00
efcca70 to
30b02e1Comparejoyeecheung
commented
Mar 6, 2026
MemberAuthor
Superseded by #62132 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Idea was suggested by @deepak1556 IIRC - instead of relying on some flag to decide whether we should install the WASM trap handler, just detect how much virtual memory is accessible and if there's not enough, don't use trap-handler-based bound checks which requires a 8-16GB virtual memory cage currently to allocate any wasm memory.
It's overall less brittle if it's mostly implemented in the upstream because the cage size might change and there might potentially be other requirements (kernel versions or hardware capabilities?) that V8 would know the best about. Going to see if this can be upstreamed or do we have to keep it on the embedder's side.
Upstream CL: https://chromium-review.googlesource.com/c/v8/v8/+/7182060