[AppCDS] -Dquarkus.package.create-appcds=true -Dquarkus.package.type=fast-jar seems broken with source/compiler 11 #32877
Labels
kind/bug
Something isn't working
Comments
|
/cc @geoand |
|
This is unfortunately caused by https://bugs.openjdk.org/browse/JDK-8265604 which has so far not been backported to JDK 17. If you do the same test with JDK 18+ (I tried JDK 20), you'll see a significant improvement. |
|
Thanks. Hmm, but the workaround is using |
I have not tried it.
|
|
Fair enough, but it smells like there might be more to it than just https://bugs.openjdk.org/browse/JDK-8265604 |
|
It likely has to do with our custom ClassLoader. But if the fix available in OpenJDK 18+ is backported to 17, the problem goes away :) |
Understood. FWIW, with my OpenJDK maintainer hat on, that's not an easy enhancement to approve. The more we know about it the better in any case. |
|
I'd be happy to work with OpenJDK folks to pinpoint the exact issue. Maybe there is something our CL does that trips AppCDS |
|
In my experiments JDK 20 from Fast-jar is (the JDK 17 data is this bug): JDK 20 from |
|
I've discovered that the list of dumped classes in the Full diff for reference: |
|
Any idea what causes that difference? |
|
@jerboaa @geoand As per https://developers.redhat.com/blog/2021/04/08/build-even-faster-quarkus-applications-with-fast-jar fast-jar results in using a custom loader. |
|
Yes, that ClassLoader is helpful to our leverage of build time processing (in cases where we don't want to use the Uber jar - which is not a good fit for containers) |
|
@ashu-mehra Yes, we came to the same conclusion. Pretty sure it's https://bugs.openjdk.org/browse/JDK-8265602 In fact, if I change the source/target level of the bytecode of the sample Even so, it's unclear to me what makes the difference in boot-up between fast-jar and uber-jar with that fixed. I still see |
Looking some more I see that the uber jar has more shared symbols (using Diff: |
jerboaa
changed the title
|
@jerboaa where you folks able to find the root cause in the JDK? In any case, I am going to close this here as there is nothing we can do on the Quarkus side |
|
@ashu-mehra any update on this? |
|
I just tried a Quarkus sample that uses RESTEasy Reactive and Jackson (which is known to be heavy at startup) and got something like the following: Bytecode target: 11 Bytecode target: 11 Bytecode target: 17 Bytecode target: 17 Bytecode target: 21 Bytecode target: 21 So there is very big jump when the target bytecode version is 17 vs 11 and then things get even better with Java 21! I am pleasantly surprised. Note: My Java 17 environment was |
geoand
added a commit
to geoand/quarkus
that referenced
this issue
Sep 26, 2023
gsmet
pushed a commit
to gsmet/quarkus
that referenced
this issue
Oct 3, 2023
Relates to: quarkusio#32877 (comment) (cherry picked from commit b815ca5)
gsmet
pushed a commit
to gsmet/quarkus
that referenced
this issue
Oct 3, 2023
Relates to: quarkusio#32877 (comment) (cherry picked from commit b815ca5)
jerboaa
added a commit
to jerboaa/quarkus-quickstarts
that referenced
this issue
Oct 23, 2023
fast-jar doesn't work well due to: quarkusio/quarkus#32877 or https://bugs.openjdk.org/browse/JDK-8265602. We cannot use JDK 17 based AppCDS dump due to quarkusio/quarkus#33069 Lets use static dump and uber jar for the demo.
holly-cummins
pushed a commit
to holly-cummins/quarkus
that referenced
this issue
Feb 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I've been playing with application class data sharing according to this guide using getting-started. What surprised me that by default (
fast-jarpackage type), the gain on using the AppCDS archive for running the app was nearly negligible:Base line (only JDK CDS, No AppCDS):
With AppCDS created using
-Dquarkus.package.create-appcds=true -Dquarkus.package.type=fast-jarduring the maven build:So we have
0.564sfor the baseline vs.0.514swith AppCDS (difference almost considered noise). I'd have expected a larger reduction on boot time. And indeed, once we switch to-Dquarkus.package.type=uber-jarwe get the expected boost:0.343s(~200ms reduction as compared to baseline):Expected behavior
-Dquarkus.package.type=fast-jarand-Dquarkus.package.create-appcds=trueamounts to about the same amount of boot time reduction than-Dquarkus.package.type=uber-jardoes (~200ms for the getting-started example in my case).Actual behavior
Boot time reduction of the app is negligible as compared to JDK CDS (the default for JDK 17+ builds these days).
How to Reproduce?
Reproducer:
getting-startedsample app.cd getting-started.JAVA_HOME=/usr/lib/jvm/java-17-openjdk ./mvnw -Dquarkus.platform.version=999-SNAPSHOT -Dquarkus.package.create-appcds=true -Dquarkus.package.type=fast-jar clean packagecd target/quarkus-app/usr/lib/jvm/java-17-openjdk/bin/java -Xlog:cds -Xshare:on -XX:SharedArchiveFile=app-cds.jsa -jar quarkus-run.jar-Xshare:on -XX:SharedArchiveFile=app-cds.jsaoptions.Output of
uname -aorverNo response
Output of
java -versionRed_Hat-17.0.6.0.10-1.fc37
GraalVM version (if different from Java)
No response
Quarkus version or git rev
6c7268b
Build tool (ie. output of
mvnw --versionorgradlew --version)maven
Additional information
When building with
-X(debug logging) theAppCDSBuildStepshows many CNFE for vertex and others, which seems to indicate a classpath problem?The text was updated successfully, but these errors were encountered: