[Feature] Node process started via Yarn 2 should use less RAM

[ulrik-s]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

The user is using Yarn 1 and installing Yarn 2 for his project. The project is suddenly using up a lot more RAM than before. This is major problem from a RAM consumption perspective. Especially if multiple node processes are running this way on a computer/server.

Example:

This is a simple example but the difference to bare node is significant.

Is there a way to reduce the memory usage?

The significant memory increase is unfortunately blocking us to use Yarn 2 properly.

Describe the solution you'd like

A node version that can load pnp modules without being started via Yarn.

[arcanis]

Makes sense - we currently never garbage collect the zip archives after we've finished reading files from them. At the very least, we should trigger one here if isMain is true. It won't cover everything (some require might be executed lazily), but it should remove a large part of the overhead:

https://github.com/yarnpkg/berry/blob/master/packages/berry-pnp/sources/loader/applyPatch.ts#L152

[arcanis]

I made a quick test and it's a bit more complex than what I said. The problem is that the wasm memory never shrinks - it can only grow. The free calls will just allow malloc to reclaim some previously allocated that is now unused.

So if we only deallocate the libzip instances at the end of the require pipeline, the memory will already have grown too large by then, and our free call will just allow further malloc to reuse this huge area now unused (which will never happen because most require calls are done when the program initializes, as I mentioned).

The garbage collection would thus need to be smarter. For example something like: when a module finishes executing, release all the libzip instances that it created.

[ulrik-s]

The parent and grandparent procecsses are seemingly expensive. Is there a way to get rid of them? or would that not free up any memory? Maybe having a bash-script that did "node --loader" could help?

[arcanis]

There's definitely something fishy going on. Even empty files use an incredible amount of vram. Replacing:

const libzip_1 = __importDefault(__webpack_require__(17));

by

const libzip_1 = {default:{_malloc:()=>0,cwrap:()=>null}};

Makes the memory usage as expected on an empty file. Something in the wasm build is causing the huge allocation, but I'm not sure what - from what I seem, the initial memory is supposed to be only 16M 🤔

[arcanis]

I wonder if htop is reporting the right size ... and why it wouldn't.

When looking at process.memoryUsage, I get the expected results:

with libzip (in MB):

foo {
  rss: 46.71875,
  heapTotal: 31.03125,
  heapUsed: 15.018180847167969,
  external: 17.62874412536621
}

without libzip (in MB):

foo {
  rss: 42.98046875,
  heapTotal: 30.27734375,
  heapUsed: 12.967483520507812,
  external: 1.3821792602539062
}

The external size only growned by the initial 16M, as expected.

[ulrik-s]

What are the corresponding htop numbers? I had to bump the RAM of our virtual test server from 2 GB to 4GB in order for the system to start up. It does seem that the higher RAM usage is "real".

[arcanis]

htop is at 16G. According to vmmap it comes from a V8-allocated block, but I don't understand why it doesn't show up in memoryUsage:

Memory Tag 255         0000000108540000-0000000188540000 [  2.0G     0K     0K     0K] ---/rwx SM=NUL
Memory Tag 255         0000000189540000-0000000388540000 [  8.0G     0K     0K     0K] ---/rwx SM=NUL
Memory Tag 255         0000065af7552000-0000065b374a3000 [  1.0G     0K     0K     0K] ---/rwx SM=NUL

[arcanis]

It seems that simply instantiating a WebAssembly.Memory instance is enough for V8 to use gigabytes of virtual memory. This is weird:

const INITIAL_TOTAL_MEMORY = 16777216;
const WASM_PAGE_SIZE = 65536;

const wasmMemory = new WebAssembly.Memory({
  "initial": INITIAL_TOTAL_MEMORY / WASM_PAGE_SIZE
});

setInterval(() => {
  const mem = process.memoryUsage();
  for (const key of Object.keys(mem))
    mem[key] = mem[key] / 1024 / 1024;
  console.log(process.pid, mem);
}, 500);

[kripken]

This is expected behavior: to make wasm loads and stores fast, wasm VMs (including v8) use the "signal handler trick" on 64-bit CPUs, where they allocate a lot of virtual memory. The wasm memory is put at the beginning of that virtual memory, and the rest is unmapped so that the CPU will trap if it is loaded from or stored to. Then by catching that signal the VM can handle loads/stores past the end of memory, which saves doing a bounds check on each memory access. I think this is something like a 10-20% speedup.

Usually allocating a bunch of virtual memory is not an issue on 64-bit machines, since it uses no physical memory, and there is plenty of address space. Is this causing an actual problem?

I'm not sure if that can be disabled, but the relevant v8/node flags are probably

  --wasm-trap-handler (use signal handlers to catch out of bounds memory access in wasm)
        type: bool  default: true
  --wasm-trap-handler-fallback (Use bounds checks if guarded memory is not available)
        type: bool  default: false