iitsoftware
commented
11 months ago I vote for this feature, too! You should implement all features and not spare out the most important one - virtual threads.
Our messaging system SwiftMQ relies on GraalVM. We force our customers to use it. We are currently in the process of moving our platform thread pools to virtual threads.
SwiftMQ includes a micro service engine called SwiftMQ Streams. With that you can inject JS (aka a Stream) into a broker. This script registers various callbacks at the engine via the Java-implemented Stream Interface during script eval. Such as listeners for messages on a queue etc. Subsequently, the callbacks are activated from the Java side and the Stream processed it accordingly.
Every Stream runs in its own Context, driven by a dedicated event loop. All event loops of all Streams are currently served from a single shared thread pool. Events from one event loop might be executed by different threads from this pool but it is ensured that only one thread accesses the Context. So every Stream is single-threaded. Because of possible different thread executions on a single event loop we may have lots of heavy-weight thread context switches. To avoid that, we plan to use a single virtual thread per event loop and let the JVM schedule them on carrier threads.
SwiftMQ Streams is also used from Flow Director which is a no-code platform, based on so-called flows where you connect flow components graphically to flows and then automatically deploy and execute them. Flows are generated to JS as SwiftMQ Stream.
SwiftMQ itself has a non-blocking design with event loops everywhere and associated thread pools for execution. We are currently refactoring everything to a virtual thread per event loop. However, the SwiftMQ Streams engine is the only part we cannot refactor because you don't support virtual threads in Truffle.
Please consider to support virtual threads in Truffle! Thanks a lot!
kassifar
wirthi
msievers
nikolafon
chumer
cjaeriksson
eregon
edgebroker
ujibang
Feature request
Is your feature request related to a problem? Please describe. I am developing an implementation of the Lua programming language on Truffle/GraalVM as a hobby project. My implementation of coroutines depends on the Loom virtual threads/continuations. However, when I compile the language using native-image (GraalVM CE 21+35.1), attempting to create a virtual thread results in
java.lang.UnsupportedOperationException: Virtual threads are not supported together with Truffle JIT compilation.Describe the solution you'd like. It would be useful if virtual threads were supported alongside Truffle JIT compilation in native images (and preferably the underlying
jdk.internal.vm.Continuationinterface as well, but I could get by without it) to have an efficient and interop-friendly way of implementing coroutines, fibers, and similar constructs in some programming languages.Describe who do you think will benefit the most. Developers of Truffle-based languages would benefit the most, especially those working on languages like Lua whose coroutines cannot be easily implemented within the framework without virtual threads/continuations.
Describe alternatives you've considered. It may be possible to use alternatives such as JavaFlow, but many of these seem to no longer be maintained, be less robust than Loom continuations, and not play well with Truffle interop.
Express whether you'd like to help contributing this feature I don't have the experience necessary to help implement this myself.