Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Loom and Structured Concurrency

javaadvent.com

Post reply on HN
Print view View original

21–30 of 111 posts

Re: Project Loom and Structured Concurrency

#21

Post by pbourke »

nfoz wrote: post #2

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…

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.

Re: Project Loom and Structured Concurrency

#22

Post by ceronman »

jillesvangurp wrote: post #11

Since the article goes out of its way to not mention Kotlin, I'll do it for them since this is both lame and more than a bit disingenuous. Arguably, Kotlin co-routines (and the Flow API) provides a very nice implementation of the exact same concepts on the JVM. As far as I know, the loom integration is already planned and probably implemented to a large degree. Mostly doing that should be straightforward as this pret…

There is an important difference with Kotlin coroutines. In Kotlin you still have the problem of colored functions [1], those marked with `suspend` and the regular functions. You can't call suspend functions from regular functions and the world is divided in blocking and non blocking APIs (e.g Thread.sleep() vs delay()). And then you have to use things like `runBlocking` to bridge these two worlds.

If I understand correctly, Loom breaks that wall completely. You don't need to mark functions as `suspend`, the runtime is just smart enough to do the right thing. For example, if you call Thread.sleep() on a regular OS thread, then that will block, but if you run it on a light weight thread, it will suspend instead, allowing the runtime to use the OS thread for another task.

And there is one more thing: because Loom is implemented at the VM level, that means that when using Lightweight threads you get all the good things you typically get with regular threads: Proper stacktraces and native debugging and profiling support.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Re: Project Loom and Structured Concurrency

#23

Post by dboreham »

pbourke wrote: post #21
nfoz wrote: post #2

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…

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

Re: Project Loom and Structured Concurrency

#24

Post by gpderetta »

pbourke wrote: post #21
nfoz wrote: post #2

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…

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.

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.

Re: Project Loom and Structured Concurrency

#25

Post by simiones »

gpderetta wrote: post #24
pbourke wrote: post #21

Earlier quoted context omitted.

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.

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.

Re: Project Loom and Structured Concurrency

#26

Post by jnwatson »

anonymousDan wrote: post #10

I don't quite get the point of the executor service with virtual threads. If they are really cheap to create then why not just create them as required? It's been a while since I programmed in Java though, am I missing something? Edit: Ah - I read the rest of the article. Using it as a synchronisation primitive makes sense I guess, if a bit clunky.

It is an unfortunate abuse of an existing facility for something quite different.

Re: Project Loom and Structured Concurrency

#27

Post by amitport »

Traubenfuchs wrote: post #15

I am still not comfortable enough with this concept to answer this question myself, but will this, by default, lead to speed ups and/or reduced resource consumption in a) application server like tomcat and b) web frameworks like Spring? Assuming it's implemented...

Probably no, but that's not the point. These server frameworks have complex code that helps balance load across threads.

Loom may make such programs simpler to write, but will not automatically give a boost to already optimized code.

Re: Project Loom and Structured Concurrency

#28

Post by kasperni »

gpderetta wrote: post #24
pbourke wrote: post #21

Earlier quoted context omitted.

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.

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.

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.

Re: Project Loom and Structured Concurrency

#29

Post by jnwatson »

I have a lot of experience using concurrency in Go, and for the last couple years have been at the bleeding edge of Python async. The tradeoffs between the two approaches are immense.

With the virtual thread model you have:

* No function coloring problem. This also means existing code is easier to port.

* possibility of transparent M:N scheduling.

* Impedence mismatch with OS primitives.

* Much more sophisticated runtime.

* Problematic task cancellation.

* Lots of care still needed for non-trivial inter-task synchronization.

With the async API model you have:

* Viral asyncification (the method color problem).

* Simpler runtime.

* Obvious and safe task cancellation.

* Completely orthogonal to parallelism (actually doing more than one thing simultaneously) for good and for bad.

* Inter-task coordination is straightforward and low-overhead even for sophisticated use cases.

* Higher initial learning curve.

I'm leaning toward liking the async approach more, but that might be just because I'm deep in the middle of it. I think the biggest argument in favor of virtual threads is the automatic parallelism; that's also the biggest argument against: free running threads require more expensive synchronization and introduce nondeterminism.

Re: Project Loom and Structured Concurrency

#30

Post by mping »

For me the real advantage is not on performance but on the programming model. I have been tinkering with Loom (and clojure) and the idea of "just" calling some library without worrying about blocking is refreshing. That means that for the most of it, you can write your code without worrying too much about some kind of callbacks or async support from your library and it just works.

Of course, for those with extreme performance requirements, they will probably have their own custom scheduler and concurrency/parallelism mechanisms but for the vast majority of jvm users out there I think Loom will be a great thing. If Loom integrates with GraalVM/native-image it would be even nicer.

Post reply on HN