Hacker News Reader

Comment by bestinterest | Hacker News Reader

Can anyone fill me in on how this compares to Java's Project Loom approach where they have said a hard no to coloring functions. What are the advantages and disadvantages of async/await vs introducing a green thread like approach for problems?

Is async/await more suitable for user interfaces?

View on HN

In Loom we can make some trade offs around our knowledge of the Java stack and the standard library.

1. We know that no JVM frame contains a raw pointer to anywhere else in the stack.

2. We know which stack frames are JVM frames, and which are native frames.

3. We know that there are unlikely to be native frames in the portion of the stack between the point where we yield control and the point we want to yield to.

4. We can change the standard library to check if we are in our new lightweight thread or not and act appropriately.

Knowing these we can avoid function coloring and push the complex management of green threads into the standard library, and reuse existing task scheduler code to manage these virtual threads, and we can work to make thread local variables etc work seamlessly with this new concurrency abstraction.

This puts us in a very different design space. We can move a portion of the stack to the heap when a thread is unmounted, and we can change things about the GC and other internal systems to make them aware of this new thing that can be in the heap.

This type of approach would be much harder in a language like swift that tends to coexist with C and other languages that use raw pointers or a non-moving GC, so I think the question is not which is the better approach but which is the better approach within your language ecosystem.

If Loom ever comes out :p, at this point I am starting to wonder if this is a case of "the right thing" against "worse is better" and maybe we just will never see the light of Loom.

You can download loom and use it right now. I am pretty sure it will one day be released.

Java is at a stage where it's clear it will continue to be a popular platform and language for decades to come. It can afford to do "the right thing" because the question it's facing is not how to attract more developers now, but how to avoid mistakes its numerous developers will pay for, and build solid foundations for many years to come. It's a common difference between young and established languages, and, naturally, Java made its own fair share of design mistakes when it was young.

Of course, there are technical differences that make certain design choices easier or harder in different languages. As aardvark179 mentions above, Java doesn't have pointers into the stack, and intermediate FFI frames are extremely rare (also due to the platform's established and large ecosystem).

(I'm the technical lead for OpenJDK's Project Loom)

According to Johnny Rotten, rock & roll died in the 70s.

Narking on grandpa's compiler is just what some kids do.

I'm very excited about Loom. I've also been waiting 3 years for it, and am probably getting impatient. I think it worries me that there still isn't any scheduled release date. And what has happened is as a user of Java, no framework has been able to develop in that time around a fiber or coroutine model, where in other languages, like C#, the TAP model has had ample time to develop and for libraries and framework to transition to it, best practices to occur, etc. While on Java we're still waiting.

Now, I actually still believe Java is doing the right thing (hence the name). And the right thing if successful is more right, thus the name. And you make a good point in that Java is already popular and can probably afford to take a really long time to bring a better async story to its table.

But lately I've been wondering if Loom can fail? It seems to still somewhat be experimental, is there any chance it wouldn't ship? That after all the hard work, it doesn't get merged into OpenJDK? Maybe it turns out to be more hassle, break too much user code, be too difficult to bring back to Graal, or fail to be natively compiled by Substrate, etc.

Hopefully not, and I'm sure you're more aware then anyone of the risks here. And I trust you and the team working on Loom. But sometimes seeing what's happening and being done in C# and other languages, I do stop and wonder if worse is better, but when Loom does arrive (if ever?), I'll probably be happy that this was the route Java took.

Implementing async/await is only a compiler change, so it can be implemented rather easily on top of any languages, the compiler transforms the code to a state machine.

co-routine (Java Loom's one, Go one, Scheme one, etc) requires to be able to serialize and deserialize a part of the stack (move the stack on the the heap and vice versa), so it's hard/impossible to implement with non managed runtimes which like in C or objective C.

In C, you can declare an address/pointer to an address on stack (using &), but with a co-routine mechanism, the addresses of parts of the stack are not constant.

If you have a managed runtime, you rewrite those kind of pointers when you copy parts of the stack back and forth.

With one stack per coroutine you do not have to move stack frames. It has different tradeoffs of course.

async/await is really just another formulation of linked stack frames, where control is explicitly yielded. At the end of the day, the thread stack state needs to be reified somehow, and all of these approaches are equivalent in power. The only difference is that now you have a type system that delineates between functions that can and cannot be shuffled between kernel threads.

The benefits that Go (and potentially Loom) provide are with the scheduler. When Go code calls into other Go code, it's fast because preemption points can be inserted by the compiler. The goroutine is parked when it is blocked (on I/O or some foreign function), and in the slow path this logic is executed on a new kernel thread.

Although the Go approach involves more overhead in the slow path, wrangling blocking code to work with the scheduler has cross-cutting implications for library design. I.e, I don't have to worry that a library I import that does file I/O will pin my goroutine to a blocked thread by using a blocking syscall.

Async/await provides a mechanism for explicit context switching between threads. This is useful when you might need to run code on specific native threads or other native tasks outside the runtime.

It seems like it would be much harder or impossible in languages that work to hide these details. How do you go from implicit blocking to explicit native thread usage?

At least Loom seems to be keeping native threads so Java code can simply fall back to that, I guess.

You can also use native threads in Go, by locking the current goroutine thread.

One way to solve it is to introduce a concept like a nursery (a la structured concurrency) and when setting it up you instruct it to create a new thread that is only used for those particular tasks.

This of course requires a scheduler that needs to handle hierarchical control of execution rather than having an unformed mass of tasks, but nurseries provide other benefits as well.

async/await is more flexible in some sense. If you run the tasks on a thread pool, it's mostly equivalent to green threads. But if you run the tasks on a single thread, you get cooperative multi-tasking. You can access mutable shared state without using locks, as long as you don't use "await" while the shared state is in an inconsistent state. For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks.

Also, here's an interesting use of async/await: software hyperthreading: https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-...

Loom's virtual threads allow you to do the same with a pluggable scheduler.

How does UI code work in Loom if you need, say, a single render thread to issue GL commands? Wouldn't you need a native thread (making Loom moot), or is there some other trick at play?

You can still pick and choose, native threads aren't going away, just like today you can make several tasks map to a single threaded.

Alright. The trick is to not use Loom virtual threads. I will say Java's Loom is ruthlessly elegant in this way.

But won't you run into issues where you don't want to call certain code from that UI thread? Isn't that "code coloring"?

Code colouring usually means it won't even compile, like on C# async/await case.

In your example, for Swing applications you should use invokeLater(Runnable r) anyway, and it doesn't matter what implements the interface.

You would use a custom scheduler to schedule many virtual threads onto a particular native thread.

I don't think this is enough. You still might interweave your draw commands, causing issues.

You can get the exact same result as with async/await.

If you have multiple virtual threads issuing non-atomic commands that must be run together and not interwoven, how does the scheduler know when it's ok to yield one thread to another without explicit support?

How can you set a shader and then draw a mesh each in two virtual threads without possibly interweaving their execution, for example?

>For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks.

... assuming any other tasks/coroutines running on the UI thread are being cooperative and not doing bad things like waiting on synchronous functions or otherwise hogging the UI thread too much. Done right, it's a big performance and maintainability win over multithreading, but when done poorly, it can result in large variance in latency/responsiveness of any individual task.

Reply on news.ycombinator.com