5 ms·

I wonder if kernel aware green threads will obscolete conventional green threads such as in Loom. https://www.phoronix.com/scan.php?page=news_item&px=Google-Us

I wonder if kernel aware green threads will obscolete conventional green threads such as in Loom. https://www.phoronix.com/scan.php?page=news_item&px=Google-User-Thread-Futex-Swap https://www.phoronix.com/scan.php?page=news_item&px=Google-U...

pron 6y ago
User-scheduled kernel threads mostly address the context-switch question (and, more generally, the choice of an appropriate scheduling algorithm), but don't help as much with the footprint, and so with the level of concurrency, L, and that's where the biggest win is. To do that requires a deeper knowledge of how the language makes use of the stack than the OS can do. Still, they have their uses, too, and the expectation is that when they arrive, Java will support them, too, as a third implementation of threads.
- deleted 6y ago
  [deleted]
- The_rationalist 6y ago
  To do that requires a deeper knowledge of how the language makes use of the stack than the OS can do. I often hear that argument but isn't the reverse argument also true? While the JVM has access to information and language semantics useful for threading, that the kernel doesn't have access to. Doesn't the kernel have access to useful information for threading that the JVM green threads doesn't have access to? The one information that come to my mind is being aware of all threads from all programs and not only the ones from the JVM. So could next generation green threads have some access to some of this information? Could this enable greater performance? If so, how? Could Google futex wait help there? they have their uses, too, and the expectation is that when they arrive, Java will support them, too, as a third implementation of threads. Great to hear that but I hope that their use cases will be well defined and not overlap too much with loom. wild idea : could the JVM loom scheduler at runtime convert a green thread into google thread & vice versa? That could help performance, especially on pathological cases? Finally, I believe that say 1000 green threads actually reduce to a thread pool of kernel threads encapsulated by the JVM, if this belief is correct, then the real kernel threads underlying the green threads could benefit from being futex wait kernel threads?
  - pron 6y ago
    > Could this enable greater performance? If so, how? I don't know. Any ideas? > Great to hear that but I hope that their use cases will be well defined and not overlap too much with loom. Supporting them would be a part of Loom. > could the JVM loom scheduler at runtime convert a green thread into google thread & vice versa? That could help performance, especially on pathological cases? Virtual threads' schedulers aren't in the VM. They're written in Java and are pluggable. But the answer to your question is yes, it's possible -- and not too hard, even -- but I don't know how much it would help.
    - The_rationalist 6y ago
      Any ideas? I'm not an expert, the only idea that I have in mind is simple: Say that you want to maximize cpu cores usage. So in that case you want to create ((N * 2) - Y) kernel threads underlying the user mode threads. Where N is the number of cpu cores and Y is the number of current kernel threads (but maybe that user space can access that information through a syscall?) This information allow optimal number of kernel threads backing the green threads. Optimal when you only want to maximize computation (and not concurrency like you explain in your blog) I would like to ask you two other things: Firstly I have seen in the Loom document that it will use restartable sequences. I find such creative use of modern Linux technology an awesome thing to do. But you might need to delay support for them: https://www.phoronix.com/scan.php?page=news_item&px=Glibc-Restart-Restartable-RSEQ https://www.phoronix.com/scan.php?page=news_item&px=Glibc-Re... Finally, I would really like you to attempt a comparison of Loom with current Kotlin coroutines. I'm sure that you have learnt a bit from them as they honestly are the state of the art most ergonomic coroutine I have ever seen, especially regarding the following points: Exceptions just works Beautiful structured concurrency You can trivially specify and adjust on the fly the "scheduler" through both its context and its dispatcher Great cancelation support Colorless (no pollution with a completable future) Beautiful integration with reactive streams reinvented, through flow. I don't expect Java Loom to be able to syntactically be as beautiful and simple as Kotlin coroutines but it would really be an accident to not be as expressive. So I hope that you will borrow all of their concepts as it's well thought, maximally expressive yet simple. So a comparison on the surface level features would be nice. But what interest me the most would be a comparison of how technically kotlin coroutines currently works and in what way loom will outperform them? (as you can already have ~1 million of coroutines) I expect better performance as you have access e.g to io_uring. I hope that Kotlin coroutines will be able to be transparently reimplemented using Loom threads, and therefore it would be very nice that the Loom's architects communicate with Kotlin architects on interoperability and reuse / synergies. Both communities bring great progress on the JVM and it's beautiful to contemplate.
MaxBarraclough 6y ago
Sounds rather like 'Light-weight processes', something Solaris used, but eventually retired. [0] Can anyone comment on the similarities/differences? [0] https://en.wikipedia.org/wiki/Light-weight_process https://en.wikipedia.org/wiki/Light-weight_process
- wahern 6y ago
  Linux switched to 1:1 threading (NPTL, added 2.4.4) before epoll existed (added 2.4.44). And in general M:N threading disappeared before massively concurrent asynchronous I/O architectures became popular.[1] Before the latter came, M:N threading was needless complexity; e.g. nobody was actively using and evolving scheduler activation kernel interfaces. And many of the benefits of M:N threading can't be realized when shoehorned into the POSIX thread model; e.g. concept of multiple, user-controlled schedulers or of explicitly passing control flow to a specific thread (yield/resume, switchto) have no place in that model. [1] Solaris had /dev/poll and NetBSD had kqueue before M:N threading went away, but the developments were relatively close in time and definitely before O(1) polling became widely used outside a few high-profile projects.
pjmlp 6y ago
Solaris had them as part of its original threading support, and Windows does as well, but they get seldom used.

pron 6y ago

User-scheduled kernel threads mostly address the context-switch question (and, more generally, the choice of an appropriate scheduling algorithm), but don't help as much with the footprint, and so with the level of concurrency, L, and that's where the biggest win is. To do that requires a deeper knowledge of how the language makes use of the stack than the OS can do. Still, they have their uses, too, and the expectation is that when they arrive, Java will support them, too, as a third implementation of threads.

deleted 6y ago
[deleted]
The_rationalist 6y ago
To do that requires a deeper knowledge of how the language makes use of the stack than the OS can do. I often hear that argument but isn't the reverse argument also true? While the JVM has access to information and language semantics useful for threading, that the kernel doesn't have access to. Doesn't the kernel have access to useful information for threading that the JVM green threads doesn't have access to? The one information that come to my mind is being aware of all threads from all programs and not only the ones from the JVM. So could next generation green threads have some access to some of this information? Could this enable greater performance? If so, how? Could Google futex wait help there? they have their uses, too, and the expectation is that when they arrive, Java will support them, too, as a third implementation of threads. Great to hear that but I hope that their use cases will be well defined and not overlap too much with loom. wild idea : could the JVM loom scheduler at runtime convert a green thread into google thread & vice versa? That could help performance, especially on pathological cases? Finally, I believe that say 1000 green threads actually reduce to a thread pool of kernel threads encapsulated by the JVM, if this belief is correct, then the real kernel threads underlying the green threads could benefit from being futex wait kernel threads?
- pron 6y ago
  > Could this enable greater performance? If so, how? I don't know. Any ideas? > Great to hear that but I hope that their use cases will be well defined and not overlap too much with loom. Supporting them would be a part of Loom. > could the JVM loom scheduler at runtime convert a green thread into google thread & vice versa? That could help performance, especially on pathological cases? Virtual threads' schedulers aren't in the VM. They're written in Java and are pluggable. But the answer to your question is yes, it's possible -- and not too hard, even -- but I don't know how much it would help.
  - The_rationalist 6y ago
    Any ideas? I'm not an expert, the only idea that I have in mind is simple: Say that you want to maximize cpu cores usage. So in that case you want to create ((N * 2) - Y) kernel threads underlying the user mode threads. Where N is the number of cpu cores and Y is the number of current kernel threads (but maybe that user space can access that information through a syscall?) This information allow optimal number of kernel threads backing the green threads. Optimal when you only want to maximize computation (and not concurrency like you explain in your blog) I would like to ask you two other things: Firstly I have seen in the Loom document that it will use restartable sequences. I find such creative use of modern Linux technology an awesome thing to do. But you might need to delay support for them: https://www.phoronix.com/scan.php?page=news_item&px=Glibc-Restart-Restartable-RSEQ https://www.phoronix.com/scan.php?page=news_item&px=Glibc-Re... Finally, I would really like you to attempt a comparison of Loom with current Kotlin coroutines. I'm sure that you have learnt a bit from them as they honestly are the state of the art most ergonomic coroutine I have ever seen, especially regarding the following points: Exceptions just works Beautiful structured concurrency You can trivially specify and adjust on the fly the "scheduler" through both its context and its dispatcher Great cancelation support Colorless (no pollution with a completable future) Beautiful integration with reactive streams reinvented, through flow. I don't expect Java Loom to be able to syntactically be as beautiful and simple as Kotlin coroutines but it would really be an accident to not be as expressive. So I hope that you will borrow all of their concepts as it's well thought, maximally expressive yet simple. So a comparison on the surface level features would be nice. But what interest me the most would be a comparison of how technically kotlin coroutines currently works and in what way loom will outperform them? (as you can already have ~1 million of coroutines) I expect better performance as you have access e.g to io_uring. I hope that Kotlin coroutines will be able to be transparently reimplemented using Loom threads, and therefore it would be very nice that the Loom's architects communicate with Kotlin architects on interoperability and reuse / synergies. Both communities bring great progress on the JVM and it's beautiful to contemplate.

MaxBarraclough 6y ago

Sounds rather like 'Light-weight processes', something Solaris used, but eventually retired. [0] Can anyone comment on the similarities/differences? [0] https://en.wikipedia.org/wiki/Light-weight_process https://en.wikipedia.org/wiki/Light-weight_process

wahern 6y ago
Linux switched to 1:1 threading (NPTL, added 2.4.4) before epoll existed (added 2.4.44). And in general M:N threading disappeared before massively concurrent asynchronous I/O architectures became popular.[1] Before the latter came, M:N threading was needless complexity; e.g. nobody was actively using and evolving scheduler activation kernel interfaces. And many of the benefits of M:N threading can't be realized when shoehorned into the POSIX thread model; e.g. concept of multiple, user-controlled schedulers or of explicitly passing control flow to a specific thread (yield/resume, switchto) have no place in that model. [1] Solaris had /dev/poll and NetBSD had kqueue before M:N threading went away, but the developments were relatively close in time and definitely before O(1) polling became widely used outside a few high-profile projects.

pjmlp 6y ago

Solaris had them as part of its original threading support, and Windows does as well, but they get seldom used.