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

1–10 of 111 posts

Re: Project Loom and Structured Concurrency

#2

Post by nfoz »

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...

Re: Project Loom and Structured Concurrency

#3

Post by technologia »

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…

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

Re: Project Loom and Structured Concurrency

#7

Post by pron »

> It does nothing for you if you have computationally intensive tasks and want to keep all processor cores busy.

I would argue this isn't concurrency at all (the job of juggling mostly independent tasks, and scheduling them to a relatively small number of processing units), but parallelism (the job of performing a single computational task faster by employing multiple processing units), and exactly the job of parallel streams.

> It doesn’t help you with user interfaces that use a single event thread.

It might. Loom allows you to plug in your own scheduler, and it is a one-liner to schedule virtual threads on the UI thread:

    var uiVirtualThreadFactory = Thread.builder().virtual(java.awt.EventQueue::invokeLater).factory();
All threads created by this factory will be virtual threads that are always "carried" by the UI OS thread. This won't currently work because each of those threads will have its own identity, and various tests in the UI code check that the current thread is actually the UI thread and not any thread that is mapped to the same OS thread. Changing these tests is something the UI team is looking into.

Re: Project Loom and Structured Concurrency

#10

Post by anonymousDan »

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.
Post reply on HN