worker: add worker.getMemoryUsage() API

[geekdroid07]

Summary

• Add worker.getMemoryUsage() so worker threads can report RSS, heap usage, external memory, and ArrayBuffer statistics.
• Introduce the native WorkerMemoryUsageTaker plus the per-isolate templates/bindings to expose this data.
• Add a regression test (test/parallel/test-worker-get-memory-usage.js) and document the API in doc/api/worker_threads.md.

Testing

• python3 tools/test.py parallel/test-worker-get-memory-usage
• ninja -C out/Debug node

[codecov]

Codecov Report

❌ Patch coverage is 77.01149% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.54%. Comparing base (17fba60) to head (56ece73).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_worker.cc	76.71%	7 Missing and 10 partials ⚠️
lib/internal/worker.js	78.57%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #60778      +/-   ##
==========================================
- Coverage   88.57%   88.54%   -0.04%     
==========================================
  Files         703      703              
  Lines      208256   208347      +91     
  Branches    40158    40174      +16     
==========================================
+ Hits       184469   184486      +17     
- Misses      15824    15851      +27     
- Partials     7963     8010      +47     

Files with missing lines	Coverage Δ
src/node_worker.h	90.90% <ø> (ø)
lib/internal/worker.js	96.16% <78.57%> (-0.36%)	⬇️
src/node_worker.cc	81.18% <76.71%> (-0.42%)	⬇️

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[addaleax]

There's no guarantee that allocator is still alive at this point

[addaleax]

Suggested change

	- version: v25.2.0
	- version: REPLACEME

[addaleax]

This should explain the relationship to worker.getHeapStatistics() and how it differs from that

[Flarna]

Isn't RSS a per process thing?
Therefore RSS value should be the same on all workers so quite pointless to read it from a different thread.

[Flarna]

Suggested change

	pr-url: https://github.com/nodejs/node/pull/REPLACEME
	pr-url: https://github.com/nodejs/node/pull/60778

[jimmywarting]

I’m currently 👎 on this direction.

I’d really prefer that we don’t further encourage the worker_threads-style Worker API in Node.js. It’s already troublesome to work with across different platforms, and it pulls us further away from Web Workers rather than closer.

We already have an open feature request for proper Web Worker support: nodejs/node#43583. I’d much rather see us move toward that goal than continue to add Node-specific methods to worker_threads.Worker like getMemoryUsage().

If this metric is important, it seems better modeled as:

something the worker explicitly reports back, e.g.:

import process from 'node:process'
postMessage(process.memoryUsage())

which can be accomplish today already.

Or something exposed via a Node-specific side-channel on the main thread, e.g. hypothetically:

process.memoryUsage(worker)

If we ever do have real Web Workers in Node, we definitely wouldn’t want globalThis.Worker.prototype.getMemoryUsage(): that’s not part of the web standard and would be yet another divergence between Node and browsers. A side-channel API like process.memoryUsage(worker) (or some equivalent) keeps this functionality in a Node-specific namespace without polluting the Worker prototype or the web worker surface.

So in summary: I think the right place for this is a Node-specific side-channel (like process.memoryUsage(worker)) rather than a new method on Worker, and we should be careful not to introduce more divergence from the Web Worker API while #43583 is still unresolved.