5 ms·

Here is the part where I admit that I am an idiot and don't actually know. All I do know is that in Java I cannot create this many threads and in the talks giv

• vlovich123 4y ago
  With Fibers you can implement user-space switching between virtual threads. For example, if a thread is going into a top-level select, switch it to a small stack putting the original large stack into a pool. On wake resume switch back to a larger stack. That’s basically what Project Loom is doing I suspect.
  • emccue 4y ago
    No, I understand how Loom limits the amount of stuff on the stack. Its just I thought threads always had those large stacks. 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.
    • vlovich123 4y ago
      Stacks are allocated statically upfront. However, you can change the size the kernel allocates, you can point them to use a custom memory space instead of the default one and you can change the stack you're running on. Also, like all memory pages, stack space isn't actually allocated until you modify it so if your stack depth doesn't get crazy large/you're not storing large objects on the stack, it's possible your 16 MB stack is only using 1 MB or so of real RAM.
• hddqsb 4y ago
  The explanation in the video is good, here is a transcription for convenience (emphasis added): > 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/kernel.html#threads-max https://www.kernel.org/doc/html/latest/admin-guide/sysctl/ke..., see also: https://stackoverflow.com/a/8849114 https://stackoverflow.com/a/8849114). On my system it's ~60,000 (with 8G RAM).
  • kevincox 4y ago
    > 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. 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.
  • chii 4y ago
    for java, i wonder if you could make the stack-size smaller to increase the number of threads possible (as long as you know your application can handle this smaller sized stack - aka no recursion etc).