You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
terminal69 opened this issue
Dec 25, 2021
· 2 comments
Labels
memoryIssues and PRs related to the memory management or memory footprint.questionIssues that look for answers.v8 engineIssues and PRs related to the V8 dependency.wasmIssues and PRs related to WebAssembly.
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
There should not be a need to reserve 10 gb of memory upfront, especially since maximum memory in WebAssembly is 4 gb. This seems like a bug.
Also when the maximum size of memory is provided, then amount of memory reserved should be adjusted accordingly - although this may not be related to the current issue, and perhaps I should submit this as a feature request.
What do you see instead?
Additional information
Due to high virtual memory usage per module, the number of modules that can be loaded in the main thread or in worker threads is limited (piscinajs/piscina#158)
The text was updated successfully, but these errors were encountered:
Mesteery
added
memory
Issues and PRs related to the memory management or memory footprint.
wasm
Issues and PRs related to WebAssembly.
labels
Dec 25, 2021
V8 intentionally allocates a significant amount of virtual memory for each WebAssembly instance (not module!). See, for example, Section 4.3.2 of WebAssembly in Node.js for an explanation.
However, it is only virtual memory. This has no effect on the resident set size (i.e., actual memory usage).
Example:
// WebAssembly module that accesses 4 bytes of memory.constwasmBytes=Buffer.from('0061736D010000000105016000017F030201000503010001071102046D61696E0000066D656D6F727902000A0C010A00410041002802000F0B0013046E616D6501070100046D61696E0203010000','hex');constmodule=newWebAssembly.Module(wasmBytes);// Create 1000 instances and prevent garbage collection.constinstances=Array(1000).fill(0).map((i)=>newWebAssembly.Instance(module));
Looking at the /proc/:pid/status file, I see the following stats:
V8 has reserved 10486392352 kB of virtual memory, i.e., approximately 10000 GiB or 10 GiB per instance, on a system that has a total of 12 GiB of usable memory (main memory + swap). The resident set size (i.e., the actual memory usage) remains at approximately 50 MiB.
In earlier versions of nodejs (prior to 17.2) trying to start a new instance once virtual memory is above 1000 GiB would result in an Out of memory: wasm memory error, limiting to about 100 WebAssembly instances.
With nodejs 17.2.0 and 17.3.0 I can start 1000 worker threads (each one loading the same wasm) on the same system.
I am not sure if high virtual memory usage would be a problem for some containerized applications.
memoryIssues and PRs related to the memory management or memory footprint.questionIssues that look for answers.v8 engineIssues and PRs related to the V8 dependency.wasmIssues and PRs related to WebAssembly.
Version
17.3.0
Platform
Linux localhost.localdomain 5.15.7-1-default #1 SMP Wed Dec 8 08:54:39 UTC 2021 (b92986a) x86_64 x86_64 x86_64 GNU/Linux
Subsystem
WebAssembly
What steps will reproduce the bug?
When loading a simple WebAssembly program that instantiates linear memory, virtual memory usage is 10GB.
For example, the following
import.wat
Converted to wasm (import.wasm) and loaded as
The full code for this particular test is available at https://github.com/terminal69/wasm-worker-memory-test/tree/b8d58649e4576f156789bf05aeac15e9ae32af8c as test1d.js
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
There should not be a need to reserve 10 gb of memory upfront, especially since maximum memory in WebAssembly is 4 gb. This seems like a bug.
Also when the maximum size of memory is provided, then amount of memory reserved should be adjusted accordingly - although this may not be related to the current issue, and perhaps I should submit this as a feature request.
What do you see instead?
Additional information
Due to high virtual memory usage per module, the number of modules that can be loaded in the main thread or in worker threads is limited (piscinajs/piscina#158)
The text was updated successfully, but these errors were encountered: