4 ms·

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.

by nfoz 6y ago

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 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.html http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...

technologia 6y ago
Thank you, I totally clicked on this thinking how could Google Loon have anything to do with this
moks 6y ago
also discussed here https://news.ycombinator.com/item?id=23201559 https://news.ycombinator.com/item?id=23201559
pbourke 6y ago
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.
- dboreham 6y ago
  There was a before time when they weren't 1:1
- gpderetta 6y ago
  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.
  - simiones 6y ago
    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.
    - anonymousDan 6y ago
      So how does it actually execute the system call under the hood? Using some kind of background OS thread pool?
      - Cojen 6y ago
        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.
  - kasperni 6y ago
    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.

by nfoz 6y ago

technologia 6y ago

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

moks 6y ago

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

pbourke 6y ago

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.

dboreham 6y ago
There was a before time when they weren't 1:1
gpderetta 6y ago
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.
- simiones 6y ago
  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.
  - anonymousDan 6y ago
    So how does it actually execute the system call under the hood? Using some kind of background OS thread pool?
    - Cojen 6y ago
      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.
- kasperni 6y ago
  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.