pressronAside from virtual threads, two big features delivered by Project Loom in JDK 21 are Structured Concurrency (https://openjdk.org/jeps/453) and Scoped Values (https://openjdk.org/jeps/446).
Structured Concurrency is a paradigm that brings the principles of structured programming to concurrent code and makes it easier to write concurrent code that cleanly deals with some of the thorniest chronic issues in concurrent programming: error handling and cancellation. In JDK 21 we delivered StructuredTaskScope, a preview API that brings structured programming to the JDK.
Because with virtual threads every concurrent task in a program gets its own thread, virtual threads and StructuredTaskScope are a match made in heaven. In addition to making concurrent code easier to write correctly, StructuredTaskScope brings structured observation: a thread dump that captures the relationships among threads.
ScopedValue is a superior alternative to ThreadLocal when it comes to its most common use: as a mechanism to associate context with a scope of code without passing method arguments. For that use case, ScopedValues are more efficient than ThreadLocals, and less prone to incorrect usage that can lead to bugs. Although they interact in an interesting way with structured concurrency, scoped value are completely orthogonal to virtual threads.
What may be coming down the line? In the short term, we’re working on fixing what may be the biggest hurdle to a transparent adoption of virtual threads: pinning due to synchronized. Currently, inside synchronized blocks or methods, IO operations that would normally release the underlying OS thread block it instead. That's "pinning", and if it happens frequently and for long durations it can harm the scalability of virtual threads.
The workaround today is to identify those instances with observation tools in the JDK and to replace them with java.util.concurrent locks, which don’t suffer from pinning. We’re working to stop synchronized from pinning so that this work won’t be needed.
Additionally, we’re working on improving the efficiency of the scheduling of IO operations by virtual threads, improving their performance further.
In the medium term we’d like to incorporate io_uring, where available, to offer scaling for filesystem operations in addition to networking operations. We may also offer custom schedulers: Virtual threads are currently scheduled by a scheduler that’s a good fit for general-purpose servers, but more exotic uses may require other scheduling algorithms, so we’d like to support pluggable custom schedulers.
Further down the line we would like to add channels (which are like blocking queues but with additional operations, such as explicit closing), and possibly generators, like in Python, that make it easy to write iterators.