Hacker News Reader

Comment by nfoz | Hacker News Reader

The article seems to assume you know what Project Loom is. (Not to be confused with Google's Project Loon, the balloon thing.)

From https://wiki.openjdk.java.net/display/loom/Main, it's an OpenJDK project:

> Project Loom is to intended to explore, incubate and deliver Java VM features and APIs built on top of them for the purpose of supporting easy-to-use, high-throughput lightweight concurrency and new programming models on the Java platform.

A bit more history/explanation here:

http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...

View on HN

To summarize: up till now, Java Threads have been 1:1 with OS threads. They’re limited to a few thousand per JVM. This project moves to an M:N threading model but retains the Thread API. It allows for millions of threads per JVM and async/await style performance of the existing synchronous Java libraries without language changes and with minimal changes to the standard library.

There was a before time when they weren't 1:1

Originally (about 20 years ago) java threads were M:N I think. How is this different? If I had to guess, they are not opaque to the VM which has more freedom to optimize them.

This is mentioned in the article: the old green threads model was not blocking aware - if a green thread scheduled on an OS thread issued a blocking call (say a listen on a socket) than the whole OS thread was blocked.

With Project Loom, if a virtual thread executes a blocking call, the virtual thread is suspended and the OS thread is free to execute another virtual thread.

So how does it actually execute the system call under the hood? Using some kind of background OS thread pool?

From what I can tell, async system calls are used whenever possible. A blocking call on a socket doesn't make a blocking system call, thus permitting the carrier OS thread to go do something else. As for file I/O, things are a bit messy. Older linux kernels don't support "true" async file I/O, and the Java NIO async file channels do use thread pools to emulate async behavior in that case.

Green threads was only available on Solaris. They did not support more than 1 cpu. They were not particular particular performant either. And on top of that had issues with calling native code.

Thank you, I totally clicked on this thinking how could Google Loon have anything to do with this

also discussed here https://news.ycombinator.com/item?id=23201559

Reply on news.ycombinator.com