39

Whilst I know questions on this have been covered already (e.g. https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads), I don't feel like I've got a satisfactory answer.

The question is: why don't JVM's support green threads anymore?

It says this on the code-style Java FAQ:

A green thread refers to a mode of operation for the Java Virtual Machine (JVM) in which all code is executed in a single operating system thread.

And this over on java.sun.com:

The downside is that using green threads means system threads on Linux are not taken advantage of and so the Java virtual machine is not scalable when additional CPUs are added.

It seems to me that the JVM could have a pool of system processes equal to the number of cores, and then run green threads on top of that. This could offer some big advantages when you have a very large number of threads which block often (mostly because current JVM's cap the number of threads).

Thoughts?

Community
  • 1
redjamjar
  • 819

3 Answers3

35

I remember the JVM abandoning green threads and moving to native threads. This was for two simple reasons: the green threads were frankly rubbish, and there was a need to support multi-core processors with the limited developer effort available at Sun.

This was a shame - green threads provide a far better abstraction, allowing concurrency to be a useful tool not a stumbling block. But green threads are no use if several hurdles can't be overcome:

  • they must use all the cpu cores available to them

  • context switching must be cheap

  • I/O may block any thread engaged in it, but not any other thread and certainly not all other threads, which was the case in some early implementations.

I've often wondered why multi-threading is so hard in Java but it's now becoming clearer - it was ultimately to do with the switch to native threads, which are:

  • good at using all the cpu cores

  • good at being truly concurrent, providing independent I/O etc

  • slow at context switching (compared with the best green thread implementations)

  • horribly greedy with memory, hence limiting the maximum usable number of them

  • a poor abstraction for any basis for expressing the real world, which is highly concurrent of course.

Nowadays, a lot of programmer time now goes into coding up non-blocking I/O, futures etc. It's a big shame we don't have a better level of abstraction.

For comparison, besides Erlang the new Go language does a good job of huge concurrency. The grand-daddy of them all remains Occam, still an ongoing research project.

Rick-777
  • 451
16

A single process faking multiple threads has a lot of problems. One of them is that all the faked threads stall on any page fault.

The alternative that you suggest, a pool of processes, has some advantages and some disadvantages. The biggest advantage, isolation of the 'threads', really wouldn't get you much here. The big disadvantage, extreme difficulty of implementation and less efficient synchronization, is the deal-killer here.

However, I do agree that there exist some applications (not Java) where a pool of processes that you could use like a pool of threads (but with more isolation) would be a great thing to have. Threads share pretty much everything. With processes, you can specifically choose what to share. To my knowledge, nobody has gone to the effort of implementing it yet.

David Schwartz
  • 4,704
15

There'll be no benefit at all for an average Java code. Java is not Erlang, and Java programmers are not in the same mindset as Erlang programmers. The language was never intended to be used this way.

If you want the true lightweight processess - use Erlang and create thousands of threads communicating via messages. In Java you'll have a dozen of threads sharing a common memory with mutexes and semaphores. It is just a different programming model, designed for a different set of problems.

SK-logic
  • 8,517