2

In the very early Java versions, JVM threads multiplexed to native OS threads. Such threads were called Green Threads. This was deprecated in the very early versions of Java and then every Java thread corresponded to an OS thread.

However, with Project Loom - where the execution context is no longer a Thread but "some" object that can execute code. But it must still multiplex to a native thread for execution, shouldn't it? If that is the case, to me this looks like going back to the Green threads.

I'm pretty sure I'm missing something that I'd like to know what it is. Can I please get some help on this?

JavaNovice
  • 1,083
  • 1
  • 12
  • 20
  • 2
    In a way, it is a return to green threads. But its implementation is closer to coroutines in other languages such as Python and C++-20. The advent of powerful routines for building event loops in operating systems such as Linux's `io_uring` and `epoll` or Windows' `WaitForMultipleObjects` plus scalability issues with running too many threads on modern many-core machines makes this concept feasible again – Homer512 Jun 11 '23 at 16:52

1 Answers1

3

Green Threads were a solution to support multi-threading on systems with no native multi-threading support at all. In such a system, a single blocking call would block the entire process, hence all threads. Further, there was no way to use SMP capabilities with Green Threads.

While conceptually related, n:1 threads on a system without multi-threading support and n:m threads on a system with multi-threading support would have looked totally different code-wise.

This is even more true with the virtual threads of project Loom as it could settle on Java side thread pool implementations which did not exist back then. So a large portion of the Virtual Threads feature has been implemented in Java.

Virtual threads can still use SMP, as their execution is delegated to pool of platform threads tailored to the number of CPU cores. A new platform thread can be started when a platform thread is about to get blocked, to keep up the parallel processing capability. But the implementers also spent effort on re-implementing blocking operations to be non-blocking under the hood, so the platform thread will only put the virtual thread into blocked or wait state and proceed to execute the next runnable virtual thread.

Of course, it would have been possible to develop Java’s multi-threading into this direction all the time (so it would have looked like an extension to Green Threads). The specification always allowed n:m mappings of Java threads to platform threads. But it was a road not taken. And if attempted back then, the result would most probably look totally different to project Loom.

Holger
  • 285,553
  • 42
  • 434
  • 765