6 ms·

> 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

> 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.

vlovich123 3y ago
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.
- nyanpasu64 3y ago
  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 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?
  - scottlamb 3y ago
    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.
    - vlovich123 3y ago
      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.
- deleted 3y ago
  [deleted]
- nitwit005 3y ago
  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.
scottlamb 3y ago
> 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.

vlovich123 3y ago

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.

nyanpasu64 3y ago
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 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?
- scottlamb 3y ago
  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.
  - vlovich123 3y ago
    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.
deleted 3y ago
[deleted]
nitwit005 3y ago
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.

scottlamb 3y ago

> 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.