Author(s)
While 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.
-
Foojay Podcast #14: Debugging Tools and Skills for Fun and Profit
Let’s talk about debugging and observability. We work with debugging all the time, but how well do we know this common practice?
Read More
-
AP-Loader: A New Way to Use and Embed async-profiler
Using async-profiler can be quite a hassle, especially when trying to use it in a library. The new ap-loader project tries to fix this!
Read More -
AsyncGetCallTrace Reworked: Frame by Frame with an Iterative Touch!
This article is the first of two articles covering the draft of a new iterator-based stack walking API, which builds the base for the follow-up article on safepoint-based profiling.
Read More
Author(s)
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.
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.