Vertx in native image throws error: This Java runtime does not support virtual threads

[rikvb]

Because vert.x uses reflection to determine if the runtime supports virtual threads, it fails when setting the ThreadingModel to VIRTUAL_THREAD in a native image. A workaround is available adding custom hints, but it would be better to either check virtual thread support without the use of reflection (if possible) or to provide hints via the reachability metadata project.

Version

Vert.x 4.5.4, java 21.0.2, spring boot 3.2.3 and the latest graalvm build tools using maven

Steps to reproduce

1. setThreadingModel(ThreadingModel.VIRTUAL_THREAD)
2. start any vert.x application build with graalvm
3. An error is thrown:

Caused by: java.util.concurrent.ExecutionException: io.vertx.core.impl.NoStackTraceThrowable: This Java runtime does not support virtual threads at java.base@21.0.2/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396) ~[io.funnal.node.management.rest.AppLauncher:na] at java.base@21.0.2/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073) ~[io.funnal.node.management.rest.AppLauncher:na]

Workaround

Workaround, based on original code in VertxImpl.java:

public class MyHints implements RuntimeHintsRegistrar {
    @Override
    public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
        try {
            Class<?> builderClass = ClassLoader.getSystemClassLoader().loadClass("java.lang.Thread$Builder");
            Class<?> ofVirtualClass = ClassLoader.getSystemClassLoader().loadClass("java.lang.Thread$Builder$OfVirtual");
            Method ofVirtualMethod = Thread.class.getDeclaredMethod("ofVirtual");
            Method nameMethod = ofVirtualClass.getDeclaredMethod("name", String.class, long.class);
            Method factoryMethod = builderClass.getDeclaredMethod("factory");

            hints.reflection().registerMethod(ofVirtualMethod, ExecutableMode.INVOKE);
            hints.reflection().registerMethod(nameMethod, ExecutableMode.INVOKE);
            hints.reflection().registerMethod(factoryMethod, ExecutableMode.INVOKE);
        } catch (ClassNotFoundException | NoSuchMethodException e) {
            throw new RuntimeException(e);
        }
    }
}

[vietj]

@rikvb as I understand this happens because the check is registered by Graal when the native image is built and instead it should be lazily done ?

[vietj]

@cescoffier is there any way we can improve this with some graal vm declaration ?

[rikvb]

@rikvb as I understand this happens because the check is registered by Graal when the native image is built and instead it should be lazily done ?

Without the explicit hints the mentioned classes and methods are not available in the native image, resulting in the check failing and vert.x thinking the runtime does not support virtual threads (even though it does).

[cescoffier]

@vietj it's typically things we do directly in Quarkus (which unfortunately cannot be replicated here).

We prefer not to use the reachability project - it's rare when one size fits all, especially around Vert.x and Netty.

We can try with something like: https://github.com/netty/netty/blob/4.1/codec/src/main/resources/META-INF/native-image/io.netty/netty-codec/generated/handlers/reflect-config.json. I can't remember what it does if the method/class/field is not available.

[vietj]

thanks @cescoffier

[vietj]

@rikvb can you provide a reproducer project with instructions ?

[rikvb]

virtual-threads-examples.zip I've attached a stripped down version of the virtual threads example with some spring boot and graal additions.

1. run 'mvn clean compile spring-boot:process-aot spring-boot:build-image -P native'
2. docker run docker.io/library/virtual-threads-examples:4.5.4

Output:

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v3.2.3)

Mar 22, 2024 4:17:46 PM org.springframework.boot.StartupInfoLogger logStarting
INFO: Starting AOT-processed HttpClientExample using Java 21.0.2 with PID 1 (/workspace/io.vertx.example.virtualthreads.HttpClientExample started by cnb in /workspace)
Mar 22, 2024 4:17:46 PM org.springframework.boot.SpringApplication logStartupProfileInfo
INFO: No active profile set, falling back to 1 default profile: "default"
Mar 22, 2024 4:17:46 PM org.springframework.boot.StartupInfoLogger logStarted
INFO: Started HttpClientExample in 0.011 seconds (process running for 0.012)
Exception in thread "main" java.util.concurrent.ExecutionException: io.vertx.core.impl.NoStackTraceThrowable: This Java runtime does not support virtual threads
        at java.base@21.0.2/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396)
        at java.base@21.0.2/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
        at io.vertx.example.virtualthreads.HttpClientExample.main(HttpClientExample.java:27)
        at java.base@21.0.2/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
Caused by: io.vertx.core.impl.NoStackTraceThrowable: This Java runtime does not support virtual threads

[vietj]

thanks @rikvb

[vietj]

I tried running it and got rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2 on my M1 macbook, any idea :-) @rikvb ?

[vietj]

since I'm building this on my laptop I would not expect this issue to happen

[vietj]

https://github.com/stephenh/ts-proto/issues/849

[vietj]

I'm able to reproduce now with the right Paketo thing (I don't know what it does, looks like it's quite complex :-) )

[vietj]

it seems we can compute this per vertx instance instead of being static, I think this would solve this problem.

[vietj]

actually this does not seem to be enough

[rikvb]

Not sure it would, unless you can prevent using reflection.

[vietj]

@rikvb could you provide a version of the reproducer that works without Spring ? I would like to use it to test native image compatibility when releasing vertx

[rikvb]

I will look into it, but I have no experience on graalvm without the spring boot maven plugin so it might take me a bit.

[rikvb]

virtual-threads-examples-nospring.zip

Ok so here's a reproducer that does not use spring. On Windows this produces an executable that prints the following:

.\virtual-threads-examples.exe
Apr 09, 2024 5:31:09 PM io.vertx.core.spi.resolver.ResolverProvider
INFO: Using the default address resolver as the dns resolver could not be loaded
Exception in thread "main" java.util.concurrent.ExecutionException: io.vertx.core.impl.NoStackTraceThrowable: This Java runtime does not support virtual threads
        at java.base@21.0.2/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396)
        at java.base@21.0.2/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
        at io.vertx.example.virtualthreads.HttpClientExample.main(HttpClientExample.java:22)
        at java.base@21.0.2/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
Caused by: io.vertx.core.impl.NoStackTraceThrowable: This Java runtime does not support virtual threads

However, to build this I need to use graalvm-jdk. In the spring-based example I used a regular OpenJDK. To get output above I used graalvm-jdk-21_windows-x64

Hope this helps.