3 ms·
Quick note that this: > Each thread easily uses an additional Megabytes of memory isn't quite the problem it seems because unless the thread actually _uses_ l
by dboreham 5y ago
Quick note that this:
> Each thread easily uses an additional Megabytes of memory
isn't quite the problem it seems because unless the thread actually _uses_ large amounts of stack, the memory consumed is mostly virtual. With today's 64-bit architectures, there is plenty of virtual address space to be burned.
- spacechild1 5y agoYes! I can't count how often I've read this when people talk about OS threads...
- funcDropShadow 5y agoBut it requires changing the virtual memory mapping tables, i.e. it requires a context switch to the kernel and back. Therefore it decreases effectiveness of TLAB caches. I.e. there is a performance cost. One that is hard to quantify for very short lived threads and only slightly better quantifiable for longer lived threads. And every argument that OS threads are good enough is in stark contrast to the length to which people go to avoid using them. I am talking about all the async libraries/patterns/language features people use to avoid using OS-level threads.
- native_samples 5y agoWell not quite. The problem is that it only takes one call tree with a deep stack to cause all that memory to be allocated (slowly, using lots of page faults) and after that, it's used. The only way to get rid of it again is to swap it out, which means if you then go ahead and do another deep call it's even slower as the kernel doesn't know what it can discard and what it can't. Deep stacks are pretty common in modern software especially for Java software.