4 ms·

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

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.

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.