3 ms·

> On the JVM, native threads are really expensive, especially in terms of memory. If you're running on Linux, this is rather less the case. People see 1MB Xss

> On the JVM, native threads are really expensive, especially in terms of memory. If you're running on Linux, this is rather less the case. People see 1MB Xss values and assume that 1MB of 'real' memory is required to spawn a thread. In reality, on a standard linux system with overcommit enabled, stack pages are only consumed as they're written to - the rest is just virtual. Possibly you're talking about something else, but I commonly see this raised as a concern about creating threads in Java.

pron 5y ago
> In reality, on a standard linux system with overcommit enabled, stack pages are only consumed as they're written to - the rest is just virtual. 1. Once stack memory is committed, it is never uncommitted, and creating a new thread is relatively expensive. 2. Committing virtual memory is done at a page granularity. These make threads far too costly to serve as a construct for any single concurrent task.
- AlisdairO 5y ago
  ...any very short lived concurrent task. A thread costs, what, 10 or 20us to create on a typical linux/x86 system? Perhaps it's more on the JVM? Look, I'm looking forward to Loom as much as anyone. It is clearly going to be a big leap forward to the java ecosystem, and I'm looking forward to some threaded model being appropriate for any job rather than just most of them. It's just I see this terror of creating a thread or two out in the wider world and it seems a touch overwrought to me.
  - pron 5y ago
    10 or 20us can be longer than some IO operations. But the direct issue with OS threads is simply that you can't realistically have too many of them, and so they limit your level of concurrency. If the number of threads you can maintain is more than the average request rate times the average latency of each transaction (if it were processed on a single thread), then you're all good; if it's less, then your server will crash as requests pile up. Fear doesn't play a role here, just Little's law.

pron 5y ago

> In reality, on a standard linux system with overcommit enabled, stack pages are only consumed as they're written to - the rest is just virtual. 1. Once stack memory is committed, it is never uncommitted, and creating a new thread is relatively expensive. 2. Committing virtual memory is done at a page granularity. These make threads far too costly to serve as a construct for any single concurrent task.

AlisdairO 5y ago
...any very short lived concurrent task. A thread costs, what, 10 or 20us to create on a typical linux/x86 system? Perhaps it's more on the JVM? Look, I'm looking forward to Loom as much as anyone. It is clearly going to be a big leap forward to the java ecosystem, and I'm looking forward to some threaded model being appropriate for any job rather than just most of them. It's just I see this terror of creating a thread or two out in the wider world and it seems a touch overwrought to me.
- pron 5y ago
  10 or 20us can be longer than some IO operations. But the direct issue with OS threads is simply that you can't realistically have too many of them, and so they limit your level of concurrency. If the number of threads you can maintain is more than the average request rate times the average latency of each transaction (if it were processed on a single thread), then you're all good; if it's less, then your server will crash as requests pile up. Fear doesn't play a role here, just Little's law.