5 ms·

Are these Virtual Threads the feature that was previously known as “Project Loom”? Lightweight threads, more-or-less equivalent to Go’s goroutines?

by pansa2 2y ago

Skinney 2y ago
Yes
giamma 2y ago
Yes, at EclipseCon 2022 an Oracle manager working on the Helidon framework presented their results replacing the Helidon core, which was based on Netty (and reactive programming) with Virtual Threads (using imperative programming). [1]. Unfortunately the slides from that presentation were not uploaded to the conference site, but this article summarizes [2] the most significant metrics. The Oracle guy claimed that by using Virtual Threads Oracle was able to implement, using imperative Java, a new engine for Helidon (called Nima) that had identical performance to the old engine based on Netty, which is (at least in Oracle's opinion) the top performing reactive HTTP engine. The conclusion of the presentation was that based on Oracle's experience imperative code is much easier to write, read and maintain with respect to reactive code. Given the identical performance achieved with Virtual Threads, Oracle was going to abandon reactive programming in favor of imperative programming and virtual threads in all its products. [1] https://www.eclipsecon.org/2022/sessions/helidon-nima-loom-based-microservices-framework https://www.eclipsecon.org/2022/sessions/helidon-nima-loom-b... [2] https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virtual-threads-130bb2ea2088 https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virt...
- draven 2y ago
  I wanted to know more, and it seems this is the presentation: https://www.youtube.com/watch?v=aYY04D4_OQA https://www.youtube.com/watch?v=aYY04D4_OQA
pgwhalen 2y ago
Yes. It's not that the feature was previously known under a different name - Project Loom is the OpenJDK project, and Virtual Threads are the main feature that has come out of that project.
tomp 2y ago
They're not equivalent to Go's goroutines. Go's goroutines are preemptive (and Go's development team went through a lot of pain to make them such). Java's lightweight threads aren't. Java's repeating the same mistakes that Go made (and learned from) 10 years ago.
- jayd16 2y ago
  Virtual threads could be scheduled pre-emptively but currently the scheduler will wait for some kind of thread sleep to schedule another virtual thread. That's just a scheduler implementation detail and the spec is such that a time slice scheduler could be implemented.
  - tomp 2y ago
    Yes, but the problem is that the spec is such that preemptive blocking doesn't need to be implemented. That means that Java programmers have to be very careful when writing code, lest they block the entire underlying (OS) thread! Again, Go already went through that experience. It was painful. Java should have learned and implemented it from the start
    - jayd16 2y ago
      I don't know. The language already has Thread.Yield. If your use case is such that you have starvation and care about it, it seems trivial to work around. Still, an annoying gotcha if it hits you unexpectedly.
    - SureshG 2y ago
      > That means that Java programmers have to be very careful when writing code From JEP 444: The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads. Also, in this scenario, i think the current scheduler (ForkJoin Pool) will use managed blocker to compensate those pinned carrier threads.

Are these Virtual Threads the feature that was previously known as “Project Loom”? Lightweight threads, more-or-less equivalent to Go’s goroutines?

by pansa2 2y ago

Are these Virtual Threads the feature that was previously known as “Project Loom”? Lightweight threads, more-or-less equivalent to Go’s goroutines?

Skinney 2y ago

Yes

giamma 2y ago

Yes, at EclipseCon 2022 an Oracle manager working on the Helidon framework presented their results replacing the Helidon core, which was based on Netty (and reactive programming) with Virtual Threads (using imperative programming). [1]. Unfortunately the slides from that presentation were not uploaded to the conference site, but this article summarizes [2] the most significant metrics. The Oracle guy claimed that by using Virtual Threads Oracle was able to implement, using imperative Java, a new engine for Helidon (called Nima) that had identical performance to the old engine based on Netty, which is (at least in Oracle's opinion) the top performing reactive HTTP engine. The conclusion of the presentation was that based on Oracle's experience imperative code is much easier to write, read and maintain with respect to reactive code. Given the identical performance achieved with Virtual Threads, Oracle was going to abandon reactive programming in favor of imperative programming and virtual threads in all its products. [1] https://www.eclipsecon.org/2022/sessions/helidon-nima-loom-based-microservices-framework https://www.eclipsecon.org/2022/sessions/helidon-nima-loom-b... [2] https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virtual-threads-130bb2ea2088 https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virt...

draven 2y ago
I wanted to know more, and it seems this is the presentation: https://www.youtube.com/watch?v=aYY04D4_OQA https://www.youtube.com/watch?v=aYY04D4_OQA

pgwhalen 2y ago

Yes. It's not that the feature was previously known under a different name - Project Loom is the OpenJDK project, and Virtual Threads are the main feature that has come out of that project.

tomp 2y ago

They're not equivalent to Go's goroutines. Go's goroutines are preemptive (and Go's development team went through a lot of pain to make them such). Java's lightweight threads aren't. Java's repeating the same mistakes that Go made (and learned from) 10 years ago.

jayd16 2y ago
Virtual threads could be scheduled pre-emptively but currently the scheduler will wait for some kind of thread sleep to schedule another virtual thread. That's just a scheduler implementation detail and the spec is such that a time slice scheduler could be implemented.
- tomp 2y ago
  Yes, but the problem is that the spec is such that preemptive blocking doesn't need to be implemented. That means that Java programmers have to be very careful when writing code, lest they block the entire underlying (OS) thread! Again, Go already went through that experience. It was painful. Java should have learned and implemented it from the start
  - jayd16 2y ago
    I don't know. The language already has Thread.Yield. If your use case is such that you have starvation and care about it, it seems trivial to work around. Still, an annoying gotcha if it hits you unexpectedly.
  - SureshG 2y ago
    > That means that Java programmers have to be very careful when writing code From JEP 444: The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads. Also, in this scenario, i think the current scheduler (ForkJoin Pool) will use managed blocker to compensate those pinned carrier threads.