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

Enhancement: AppCDS support #166

Open
msgilligan opened this issue Dec 15, 2020 · 4 comments
Open

Enhancement: AppCDS support #166

msgilligan opened this issue Dec 15, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@msgilligan
Copy link

After reading Smaller, Faster-starting Container Images With jlink and AppCDS I'm thinking it might be possible to achieve faster startup in jlinked/jpackaged apps using AppCDS.

Would it make sense to add this to badass-jlink-plugin?

@msgilligan
Copy link
Author

More info here: https://www.morling.dev/blog/building-class-data-sharing-archives-with-apache-maven/

It would probably make sense for there to be a separate Gradle plugin for AppCDS, but the badass-jink-plugin could have an option to apply it as part of the build process.

@norbert-gaulia
Copy link

It does not work with -module-path, and it requires Shadow jar. I've tried only with badass-runtime, works flawless. Everything can be easily done with exec task on Gradle, although some libs like okhttp3 requires full exclusion from classes.txt so there is user knowledge involved about what is cached.
The other thing is that collection of classes is done while running JVM, which would add another complexity for on top of this Badass plugin.
AppCDS concept is great, works fine with Java 11 and Javafx, i've got loading times halved in busy fx app.

@siordache
Copy link
Member

Since Java 11, CDS also supports --module-path.

I added experimental support for CDS in badass-jlink 2.23.0 and badass-runtime 1.12.0:

runtime {
    ...
    enableCds()
}

It requires Java 11+ in badass-jlink and Java 13+ in badass-runtime.

In the case of badass-runtime, the plugin does two things:

  • creates a base CDS archive of the image by executing java -Xshare:dump
  • configures the start scripts to either create a dynamic AppCDS archive (using the -XX:ArchiveClassesAtExit option) or to use the existing one (using -XX:SharedArchiveFile)
    (See the documentation for more details.)

In the case of badass-jlink, the situation is simpler: only the base CDS archive of the image is needed, because the modular application is also part of the custom runtime image.

I would love your feedback.

@siordache
Copy link
Member

Actually, a dynamic AppCDS archive also makes sense in the case of badass-jlink, when customImage is used.
I added this in 2.23.1 (see the documentation).

@airsquared airsquared added the enhancement New feature or request label Sep 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants