OpenJDK Draft Proposal Would Make Concurrent Programming Far Easier, While Making More Efficient Use of Hardware Resources
Virtual threads are being proposed for Java in an effort to dramatically reduce the effort required to write, maintain, and observe high-throughput concurrent applications. A draft JDK Enhancement Proposal (JEP) from Oracle, filed this week, calls for a preview of virtual threads as part of the standard edition of Java. Virtual threads would supplement Java’s platform threads, which represent operating system threads, with a lightweight user-mode thread implementation that would make more efficient use of available hardware, with dramatically reduced costs.
Threads, the proposal notes, are useful for representing a unit of concurrency, such as a transaction. Java’s current implementation of Thread consumes an OS thread for each Java thread, and OS threads are scarce and costly. A modern server can handle orders of magnitude more concurrent transactions than OS threads.
Developers writing high-throughput server software have had to share threads among transactions to make efficient use of hardware. This was done using thread pools that would loan threads to one transaction after another to save on the cost of creating threads for each one. When this was not enough, developers began returning threads to the pool even in the middle of a transaction when waiting on I/O. This results in an asynchronous style of programming that requires a separate, incompatible set of APIs and makes troubleshooting, debugging, observation, and profiling very difficult.
Virtual threads, which are user-mode implementations of java.lang.Thread that do not block OS threads, enable near-optimal hardware utilization. Virtual threads allow a high level of concurrency, along with high throughput, while the program remains harmonious with the thread-based design of the Java platform and tools. Virtual threads are to platform threads what virtual memory is to physical RAM: a mechanism that offers a plentiful “virtual” resource through an automatic mapping to the underlying physical resource.
There is no need to learn a new programming model to use virtual threads, the proposal states. Developers who use Java to write concurrent applications already know the model. However, developers would need to unlearn old habits that arose out of necessity because of threads’ high cost, particularly the use of thread pools that are useful only when the resource they are pooling is scarce or costly to create.
Virtual threads are instances of java.lang.Thread implemented by the JDK in such a manner that allows for many active instances to coexist in the same process. The semantics of virtual threads are identical to platform threads, except that they belong to a single ThreadGroup and cannot be enumerated.
The proposal, authored by Ron Pressler and Alan Bateman, both consulting members of the Oracle technical staff, does not specify a release of standard Java that would feature virtual threads. The current release is JDK 17, published in September.