Loom is just HyperThreading in Java
Johannes BechbergerWhile sitting in Cay Horstmann’s “Looming Changes in Java Concurrency” talk at BaselOne, I had an epiphany: Aren’t virtual threads with Loom just a version of HyperThreading on the JVM?
Both try to utilize a computation resource fully, be it hardware core or platform thread, by multiplexing multiple tasks onto it, despite many tasks waiting regularly for IO operations to complete:
When one task waits, another can be scheduled, improving overall throughput. This works especially well when longer IO operations follow short bursts of computation.
There are, of course, differences between the two, most notably: HyperThreading doesn’t need the tasks to cooperate, as Loom does, so a virtual core can’t starve other virtual cores. Also noteworthy is that the scheduler for Hyper-Threading is implemented in silicon and cannot be configured or even changed, while the virtual thread execution can be targeted to one’s needs.
I hope you found this small insight helpful in understanding virtual threads and putting them into context. You can find more about these topics in resources like JEP 444 (Virtual Threads) and the “Hyper-Threading Technology Architecture and Microarchitecture” paper.
This article is part of my work in the SapMachine team at SAP, making profiling and debugging easier for everyone. This article appeared originally on my personal blog mostlynerdless.de.
Found a mistake, or something to add? Edit this page on GitHub
Johannes Bechberger
A JVM developer working on profilers and their underlying technology, e.g. JEP Candidate 435, in the SapMachine team at SAP.
Discussions on the previous Foojay site
4 comments left on this article in 2023, kept from the previous WordPress version of foojay.io. They are an archive and are closed for replies — use the discussion above to add to the conversation.
I have a feeling that these two things complement each other and not contradict. IMO they exist on different architectural levels.
Virtual threads in Java (together with structured concurrency – JEP 437) greatly simplify writing non-blocking multithreaded code.
Technically, at the bottom, hyperthreaded hardware runs it all the same – it does not care what it executes.
With Java virtual threads and structured concurrency developing scalable applications becomes much easier.
I agree, structured concurrency will make Project Loom far more useful. Currently it is just useful for a small portion of all use cases of multi-threading.
i’m honestly confuse, while i know it’s really great improvement java will have virtual threads.
But isn’t kotlin already achieve virtual threads, just by using normal thread on java?
Kotlin’s virtual threads are implemented differently and offer different pro’s and con’s. There are many great resources out there covering the differences, for example https://www.baeldung.com/kotlin/java-kotlin-lightweight-concurrency.