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

Remove GraalVM internal class usage for JDK11 compatibility #5854

Merged
merged 1 commit into from
Dec 2, 2019

Conversation

gwenneg
Copy link
Member

@gwenneg gwenneg commented Nov 29, 2019

Fixes #5682

@gwenneg gwenneg added the env/graalvm-java11 Relating to using GraalVM native image generation on Java 11 label Nov 29, 2019
@gwenneg
Copy link
Member Author

gwenneg commented Nov 29, 2019

This PR is a first step towards our GraalVM compatibility with JDK 11. I only had time to check it doesn't break the Quarkus build with JDK 8 last night, I will run the test with JDK 11 tonight.

It fixes the runtime initialization for sure, but the runtime reinitialization will probably fail during the native image generation since the RuntimeClassInitializationSupport class is still used in our generated bytecode (but it was removed from the Quarkus sources).

One thing I've started investigating is the possibility to stop reinitializing classes at runtime since it was a hack (according to a comment in our sources) from the beginning and GraalVM deprecated the API option: https://github.com/oracle/graal/blob/e0cb8e79782f4d863180c9ce84519c634922cbfe/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/classinitialization/ClassInitializationFeature.java#L124-L126. We only have a few cases where this "hack" is used in Quarkus.

@gwenneg gwenneg force-pushed the issue-5682-graalvm-jdk11 branch 2 times, most recently from 98ef4ea to e2d0d27 Compare December 2, 2019 00:21
@gwenneg gwenneg changed the title [WIP] Replace GraalVM internal class usage with GraalVM API classes Remove GraalVM internal class usage for JDK11 compatibility Dec 2, 2019
@gwenneg gwenneg added this to the 1.1.0 milestone Dec 2, 2019
@gwenneg gwenneg marked this pull request as ready for review December 2, 2019 00:32
@gwenneg gwenneg force-pushed the issue-5682-graalvm-jdk11 branch from e2d0d27 to d54c18c Compare December 2, 2019 00:38
@gwenneg
Copy link
Member Author

gwenneg commented Dec 2, 2019

The current code of this PR seems to be enough to fix the GraalVM internal class usage in Quarkus, which is a requirement for the Quarkus sources compatibility with GraalVM 19.3.0, JDK 11 edition. It was successfully tested with several native builds including quarkus-integration-test-kafka which is one of the few builds reinitializing classes at runtime. The tests were run using both the quay.io/quarkus/ubi-quarkus-native-image:19.3.0-java11 image and a local GraalVM 19.3.0 CE installation.

Since it is not breaking anything in the master (JDK 8) CI, I think it is safe to be merged now even if the GraalVM 19.3.0 support is not ready yet (see #5358).

If you want to test Quarkus with GraalVM 19.3.0 and JDK 11 before this PR is merged, you will need to checkout #5358 and then cherry-pick the commit from this PR. I'll rebase #5358 on master as soon as this one is merged.

I didn't spend much time investigating the possibility to stop reinitializing classes at runtime, but that's still on my TODO list and will be treated in another PR if there's something to merge eventually.

cc @bobmcwhirter, @dmlloyd, @Sanne

@dmlloyd dmlloyd merged commit 75c416d into quarkusio:master Dec 2, 2019
@gwenneg
Copy link
Member Author

gwenneg commented Dec 2, 2019

Thanks for reviewing this @dmlloyd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
env/graalvm-java11 Relating to using GraalVM native image generation on Java 11
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support GraalVM / native image builds using the GraalVM Java 11 build
2 participants