Setting UV_THREADPOOL_SIZE environment variable to 128 cause a huge committed memory for node.exe

[lgwrld]

Version

v22.14.0

Platform

Microsoft Windows NT 10.0.19045.0 x64

Subsystem

libuv

What steps will reproduce the bug?

Setting the UV_THREADPOOL_SIZE environment variable to a value like 64 or 128
Run this sample.js code

const dns = require('dns');
dns.lookup('localhost', () => {});
setTimeout(() => {}, 300000);

How often does it reproduce? Is there a required condition?

After having set the UV_THREADPOOL_SIZE environment variable to a value like 64 or 128 it is 100% reproducible

What is the expected behavior? Why is that the expected behavior?

Using the UV_THREADPOOL_SIZE set to the default (4) this is the memory usage from Windows Resource Monitor

Image         Commit (KB)    Working Set (KB)
node.exe      48,316         28,156

Increasing UV_THREADPOOL_SIZE it is expected a small increase of memory.

From libuv docs "The threadpool is global and shared across all event loops. When a particular function makes use of the threadpool (i.e. when using uv_queue_work() libuv preallocates and initializes the maximum number of threads allowed by UV_THREADPOOL_SIZE. This causes a relatively minor memory overhead (~1MB for 128 threads) but increases the performance of threading at runtime."

What do you see instead?

Memory usage from Windows Resource Monitor

Image         Commit (KB)    Working Set (KB)
node.exe      1,068,336      30,708

Additional information

No response

[bnoordhuis]

I changed that in libuv/libuv@73b0c1f94 because the old limit kept tripping up users¹ but apparently I forgot to update that part of the documentation. I'll fix that in libuv, thanks for the report.

¹ As in: operation X worked on the main thread but started crashing the moment it was moved into the thread pool.