[dragonwriter]

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

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_]

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

[cbsmith]

The old JDK 1.1 Developer's Guide had a page on the different thread models: https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqk/inde...

At the time, Solaris had the only "certified" JVM that did M:N threads, so they really liked to make a big deal about it.

You could control N through a JNI call to thr_setconcurrency. Not portable, but it worked. That particular capability was almost always not helpful.

[truffdog]

It was Solaris only, so there is definitely an asterisk somewhere.

[cbsmith]

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

[jjtheblunt]

I worked in Solaris internals for a while at Sun during the early java era, and Solaris threading definitely did multiplexing of userspace onto os, and then os onto cores.

Do you have a citation (because I can't find one) specifying your assertion that original Java green threads were not analogous to Solaris user -> os -> hardware multiplexing?

[dragonwriter]

> Do you have a citation (because I can't find one) specifying your assertion that original Java green threads were not analogous to Solaris user -> os -> hardware multiplexing?

I was writing from memory of second-hand after-the-fact recitations of the history. Doing some followup research prompted by your question, if I understand this document [0] correctly, Java initially had N:1 green threads on Solaris, then M:N green threads on Solaris with 1:1 native threads on Unix and Windows.

[0] https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/

[jjtheblunt]

thank you!