Hacker News Reader

Comment by codeflo | Hacker News Reader

> OS threads have a large pre-allocated stack, which increases per-thread memory overhead.

It should be noted that AFAIK on all modern operating systems, only one page of the stack is actually allocated on thread creation, and the rest is merely reserved address space that will be allocated on demand.

That doesn't make this point wrong: 4 KB is still a lot more than the couple of bytes a future might need. And setting up the page table is part of what makes spawning threads so expensive.

View on HN

That doesn’t really matter because in a long running process it’ll grow to use whatever your deepest call stack is. Matters less when you have few threads, matters a lot more when you have lots.

Can you have the runtime run a job every second, to trim thread stack depths and return memory to the kernel (whatever was meant by https://www.youtube.com/watch?v=kPR8h4-qZdk&t=1150s) while holding a FFI mutex (or a sharded one), and have every C function call first lock the mutex and expand the stack to the necessary depth?

Yes, you can use madvise(MADV_FREE) to return the RAM on Linux. I've seen a thread pool library that does this. I don't remember how this part works, but I think it's possible to maintain a high water mark in some inexpensive fashion to know when it's worth making this call.

Fucking with memory maps like that is super expensive and I wouldn’t advise it in any part that’s performance critical due to the cross CPU TLB flush that syscall will entail.

People have written code that tries to keep a short stack to prevent this.

That was one way to scale up to a large number of clients when memory was more limited.

> That doesn't make this point wrong: 4 KB is still a lot more than the couple of bytes a future might need.

It makes the memory usage acceptable in many contexts. E.g., 4 KiB is small compared to a socket buffer. YMMV.

> And setting up the page table is part of what makes spawning threads so expensive.

Stacks can be reused.

Reply on news.ycombinator.com