3 ms·

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

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

by pron 6y ago

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.