5 ms·

Are we coming full circle going back a variant of the original Java green threads?

hashmash 5y ago
Not quite. The original green threads were seen as more of a hack until Solaris supported true threads. Green threads could only support one CPU core, and so without a major redesign, it was a dead end.
AtlasBarfed 5y ago
Basically yes. Longer answer: devs back in the day couldn't really grok the difference between green and real threads. Java made its bones as an enterprise language, which can have smart programmers, but they will conversely not be closer-to-metal knowledgewise. Too many devs back in the day expected a java thread to be a real thread, so java re-engineered to accomodate this. I think the JDK/JVM teams also viewed it as a maturation of the JVM to be directly using OS resources so closely across platforms, rather than "hacking" it with green threads. These days, our high performance fanciness means the devs are demanding green thread analogues, and go/elixir/others are seemingly superior because of those. So to remain competitive in the marketplace, Java now needs threads that aren't threads even though Java used to have threads that weren't threads.
cogman10 5y ago
Yes and no. The new Loom threads will be much lighter weight than the original Java green threads. Further, the entire IO infrastructure of the JVM is being reworked for Loom to make sure the OS doesn't block the VM's thread. What's more, Loom does M:N threading. Same concept, very different implementation.
- iamcreasy 5y ago
  So, with Loom now we can tell exactly in which order theses threads were executed as it's not up to OS to decide thread execution order anymore?
  - cratermoon 5y ago
    > we can tell exactly in which order theses threads were executed Everything I've ever been taught about multi-threading, parallelism, and concurrency says never to make any assumptions about execution order. What are you doing that your care about it?
    - iamcreasy 5y ago
      Replay system.
dragonwriter 5y ago
> Are we coming full circle going back a variant of the original Java green threads? There are basically two kinds of green threads: (1) N:1, where one OS thread hosts all the application threads, and (2) M:N, where M application threads are hosted on N OS threads. Original Java (and Ruby, and lots of other systems before every microcomputer was a multicore parallel system) green threads were N:1, which provide concurrency but not parallelism, which is fine when your underlying system can't do real parallelism anyway.) Wanting to take advantage of multicore systems (at least, in the Ruby case, for underlying native code) drove a transition to native threads (which you could call an N:N threading model, as application and OS threads are identical.) But this limits the level of concurrency to the level of parallelism, which can be a regression compared to N:1 models for applications where the level of concurrency that is useful is greater than the level of parallelism available. What lots of newer systems are driving toward, to solve that, are M:N models, which can leverage all available parallelism but also provide a higher degree of concurrency.
- cbsmith 5y ago
  Java had M:N green thread models a LOOOOONG time ago. And Linux tried M:N thread implementations specifically to improve thread performance. In both cases, it turned out that just using 1:1 native threads ended up being a net win.
  - hawk_ 5y ago
    i am not aware of M:N thread builtin in Java even from long time ago, at least not in a way that you could control N
    - truffdog 5y ago
      It was Solaris only, so there is definitely an asterisk somewhere.
      - cbsmith 5y ago
        It was all very long ago, but the NGPT project did M:N threading on Linux (https://web.archive.org/web/20020408103057/http://www-124.ibm.com/developerworks/oss/pthreads/ https://web.archive.org/web/20020408103057/http://www-124.ib...). There were also a number of M:N JVM implementations that were particularly popular in the soft-realtime space back in the early 2000's. One of the fun trends with computing is that as hardware, software, and applications evolve, ideas that were once not terribly useful suddenly become useful again. It's entirely possible that M:N threads for the JVM is one of those cases, but it's NOT a new idea.
neeleshs 5y ago
This gives some color - https://blogs.oracle.com/javamagazine/going-inside-javas-project-loom-and-virtual-threads https://blogs.oracle.com/javamagazine/going-inside-javas-pro...
- carimura 5y ago
  and also many resources direct from the source (those that are working on Loom): https://inside.java/tag/loom https://inside.java/tag/loom
avereveard 5y ago
More like the many-to-many threading model of the Solaris implementation of the JVM

Not quite. The original green threads were seen as more of a hack until Solaris supported true threads. Green threads could only support one CPU core, and so without a major redesign, it was a dead end.

AtlasBarfed 5y ago

Basically yes. Longer answer: devs back in the day couldn't really grok the difference between green and real threads. Java made its bones as an enterprise language, which can have smart programmers, but they will conversely not be closer-to-metal knowledgewise. Too many devs back in the day expected a java thread to be a real thread, so java re-engineered to accomodate this. I think the JDK/JVM teams also viewed it as a maturation of the JVM to be directly using OS resources so closely across platforms, rather than "hacking" it with green threads. These days, our high performance fanciness means the devs are demanding green thread analogues, and go/elixir/others are seemingly superior because of those. So to remain competitive in the marketplace, Java now needs threads that aren't threads even though Java used to have threads that weren't threads.

cogman10 5y ago

Yes and no. The new Loom threads will be much lighter weight than the original Java green threads. Further, the entire IO infrastructure of the JVM is being reworked for Loom to make sure the OS doesn't block the VM's thread. What's more, Loom does M:N threading. Same concept, very different implementation.

iamcreasy 5y ago
So, with Loom now we can tell exactly in which order theses threads were executed as it's not up to OS to decide thread execution order anymore?
- cratermoon 5y ago
  > we can tell exactly in which order theses threads were executed Everything I've ever been taught about multi-threading, parallelism, and concurrency says never to make any assumptions about execution order. What are you doing that your care about it?
  - iamcreasy 5y ago
    Replay system.

dragonwriter 5y ago

> Are we coming full circle going back a variant of the original Java green threads? There are basically two kinds of green threads: (1) N:1, where one OS thread hosts all the application threads, and (2) M:N, where M application threads are hosted on N OS threads. Original Java (and Ruby, and lots of other systems before every microcomputer was a multicore parallel system) green threads were N:1, which provide concurrency but not parallelism, which is fine when your underlying system can't do real parallelism anyway.) Wanting to take advantage of multicore systems (at least, in the Ruby case, for underlying native code) drove a transition to native threads (which you could call an N:N threading model, as application and OS threads are identical.) But this limits the level of concurrency to the level of parallelism, which can be a regression compared to N:1 models for applications where the level of concurrency that is useful is greater than the level of parallelism available. What lots of newer systems are driving toward, to solve that, are M:N models, which can leverage all available parallelism but also provide a higher degree of concurrency.

cbsmith 5y ago
Java had M:N green thread models a LOOOOONG time ago. And Linux tried M:N thread implementations specifically to improve thread performance. In both cases, it turned out that just using 1:1 native threads ended up being a net win.
- hawk_ 5y ago
  i am not aware of M:N thread builtin in Java even from long time ago, at least not in a way that you could control N
  - truffdog 5y ago
    It was Solaris only, so there is definitely an asterisk somewhere.
    - cbsmith 5y ago
      It was all very long ago, but the NGPT project did M:N threading on Linux (https://web.archive.org/web/20020408103057/http://www-124.ibm.com/developerworks/oss/pthreads/ https://web.archive.org/web/20020408103057/http://www-124.ib...). There were also a number of M:N JVM implementations that were particularly popular in the soft-realtime space back in the early 2000's. One of the fun trends with computing is that as hardware, software, and applications evolve, ideas that were once not terribly useful suddenly become useful again. It's entirely possible that M:N threads for the JVM is one of those cases, but it's NOT a new idea.

neeleshs 5y ago

This gives some color - https://blogs.oracle.com/javamagazine/going-inside-javas-project-loom-and-virtual-threads https://blogs.oracle.com/javamagazine/going-inside-javas-pro...

carimura 5y ago
and also many resources direct from the source (those that are working on Loom): https://inside.java/tag/loom https://inside.java/tag/loom

avereveard 5y ago

More like the many-to-many threading model of the Solaris implementation of the JVM