Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport of b957ee40f302d54edf704b36120ef21fe977453a on top of vm-23.1.3 #9516

Conversation

JaroslavTulach
Copy link
Contributor

@JaroslavTulach JaroslavTulach commented Aug 17, 2024

According to @eregon this is the fix that should be backported into GraalVM based on JDK21 to make use of Helidon Graal.js possible.

Steps to reproduce the original problem as provided by @4e6:

$ git clone https://github.com/4e6/helidon-quickstart-se
$ cd helidon-quickstart-se 
$ git checkout 00b472fc830f54a75e30884ebd153d74ea4c407d
$ JAVA_HOME=/graalvm-community-openjdk-21.0.2 13.1/ mvn -Pnative-image install -DskipTests
 ./target/helidon-quickstart-se 
2024.08.17 16:21:40.664 Logging at runtime configured using classpath: /logging.properties
Exception in thread "main" java.lang.UnsupportedOperationException: Virtual threads are not supported together with Truffle JIT compilation.
        at [email protected]/java.lang.Thread.ofVirtualWithoutLoom(Thread.java:674)
        at [email protected]/java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor(Executors.java:269)
        at io.helidon.webserver.LoomServer.<init>(LoomServer.java:74)
        at io.helidon.webserver.WebServer.create(WebServer.java:45)
        at io.helidon.webserver.WebServerConfig$Builder.build(WebServerConfig.java:662)
        at io.helidon.examples.quickstart.se.Main.main(Main.java:43)

with here in provided fix I can build GraalVM as:

graal/vm$ mx --java-home ~/bin/labsjdk-ce-21.0.2-jvmci-23.1-b33/ --env ce --native-image=nic build
graal/vm$ mx --java-home ~/bin/labsjdk-ce-21.0.2-jvmci-23.1-b33/ --env ce --native-image=nic graalvm-home
/graal/sdk/mxbuild/linux-amd64/GRAALVM_350A482ABE_JAVA21/graalvm-350a482abe-java21-23.1.3

then I can replay the above steps with the newly built GraalVM at /graal/sdk/mxbuild/linux-amd64/GRAALVM_350A482ABE_JAVA21/graalvm-350a482abe-java21-23.1.3 and everything runs smoothly:

$ git clone https://github.com/4e6/helidon-quickstart-se
$ cd helidon-quickstart-se 
$ git checkout 00b472fc830f54a75e30884ebd153d74ea4c407d
$ JAVA_HOME=/graal/sdk/mxbuild/linux-amd64/GRAALVM_350A482ABE_JAVA21/graalvm-350a482abe-java21-23.1.3 mvn -Pnative-image install -DskipTests
 ./target/helidon-quickstart-se 
2024.08.17 16:25:10.047 Logging at runtime configured using classpath: /logging.properties
2024.08.17 16:25:10.065 Helidon SE 4.0.11 features: [Config, Encoding, Health, Media, Metrics, Observe, WebServer]
2024.08.17 16:25:10.065 [0x597ba75e] http://0.0.0.0:8080 bound for socket '@default'
2024.08.17 16:25:10.065 Started all channels in 0 milliseconds. 22 milliseconds since JVM startup. Java 21.0.2 13-jvmci-23.1-b33
WEB server is up! http://localhost:8080/simple-greet

Please consider my PR or your own backport b957ee4 for backporting into release/graal-vm/23.1 branch. CCing @chumer.

@oracle-contributor-agreement oracle-contributor-agreement bot added the OCA Verified All contributors have signed the Oracle Contributor Agreement. label Aug 17, 2024
@JaroslavTulach JaroslavTulach marked this pull request as draft August 17, 2024 14:14
@JaroslavTulach JaroslavTulach marked this pull request as ready for review August 17, 2024 14:26
@jerboaa
Copy link
Collaborator

jerboaa commented Aug 22, 2024

@zakkak FYI. Probably something to discuss for https://github.com/graalvm/graalvm-community-jdk21u

@JaroslavTulach
Copy link
Contributor Author

JaroslavTulach commented Aug 27, 2024

FYI: @ola-lis has created an official ticket in My Oracle Support requesting fix for the Helidon 4 Graal.js on native-image for JDK21 problem:

My Oracle Support request

Is this the right way for an Oracle Java SE JDK and JRE licensee to request help from Oracle GraalVM team officially?

@wirthi
Copy link
Member

wirthi commented Aug 27, 2024

@JaroslavTulach we will have a look at your PR next week, August is vacation time.

If that is easy to backport, we can do it. You change seems quite big already; @peter-hofer will have a look and decide how easy and reasonable it is to merge that to our GraalVM-23.1. branch.

@peter-hofer
Copy link
Member

Tracked internally as GR-58288.

@peter-hofer peter-hofer self-assigned this Sep 19, 2024
@JaroslavTulach
Copy link
Contributor Author

Thank you all for your feedback and explanations.

I should probably add that I have experimented with @Substitute annotation and I almost got my application running. I would succeed completely if I was able to override the existing substitution of Thread.ofVirtual to return null. But right now it is not possible to override existing substitution with another substitution. native-image complains about duplicated substitutions for the same method.

I am mentioning this for completeness. Obviously real support for my use-case would be better than hacking with @Substitutions.

@christianwimmer
Copy link

We can add a way to disable existing substitutions via an option, and backport that option to the LTS versions

@peter-hofer
Copy link
Member

How would returning null from ofVirtual help you?
I suppose what you would be doing is to use the option to disable several substituting methods (e.g. -H:DisableSubstitutions=com.oracle.svm.core.thread.Target_java_lang_Thread.ofVirtualWithoutLoom) and introduce new substitutions that provide the behavior that you want.

@JaroslavTulach
Copy link
Contributor Author

I suppose what you would be doing is to use the option to disable several substituting methods (e.g. -H:DisableSubstitutions=com.oracle.svm.core.thread.Target_java_lang_Thread.ofVirtualWithoutLoom) and introduce new substitutions that provide the behavior that you want.

Yes, -H:DisableSubstitutions=com.oracle.svm.core.thread.Target_java_lang_Thread.ofVirtualWithoutLoom and my own substitutions would be ideal!

How would returning null from ofVirtual help you?

Helidon is using Executors.newThreadPerTaskExecutor(Thread.ofVirtual());. I already have substitution for newThreadPerTaskExecutor - I just need ofVirtual() to not crash. But that's irrelevant. With -H:DisableSubstitutions=... we should be able to do it properly.

Thank you for helping Enso.

@JaroslavTulach
Copy link
Contributor Author

Helidon team has released version 4.1.2 which contains a fix and allows us to simply apply few substitutions and get our application working in native image: enso-org/enso#10783 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport OCA Verified All contributors have signed the Oracle Contributor Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants