All I do know is that in Java I cannot create this many threads and in the talks given about Project Loom this is given as the explanation as to why.
https://www.youtube.com/watch?v=EO9oMiL1fFo @ ~4:00
Is it maybe not the actual spawning but some "switch" that flips once you start using the thread?
I'll update the post or leave a comment with a correction once I understand exactly what you mean
> OpenJDK implements threads as thin wrappers around the OS thread [...] OS threads are expensive, by which I mean that we cannot have too many of them. Maybe a few thousand active ones, maybe ten thousand active ones, but that's about it. And the reason for that is that the OS doesn't know the various languages, and the most costly component of a thread is its stack, and the operating system doesn't know how the various languages it might support makes use of the stack. So it must address the worst case and allocate a very large stack. It's usually on a megabyte scale. And even though we use virtual memory and not all of it is committed to physical memory, once we touch a page it becomes committed – it can't be uncommitted again because the OS doesn't know how the stack is used. And in any event, all the operations are done at a page granularity which is 4k, it's also not that small.
There may also be arbitrary OS-specific limits. For example on Linux there is system-wide limit on the number of threads, controlled by /proc/sys/kernel/threads-max (docs: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/ke..., see also: https://stackoverflow.com/a/8849114). On my system it's ~60,000 (with 8G RAM).
I wonder if this could be solved by the code itself. Every so often tell the OS that you don't need all of the stack pages that are currently unused.
Of course getting the "every so often" right to avoid a huge slowdown in edge cases isn't easy.
Based on what the top person said, I'm thinking that they don't get a large stacks until they cross some threshold of use, but I want to make sure.