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

Support CDS #7580

Open
jacobmarshmallow opened this issue Sep 9, 2024 · 4 comments
Open

Support CDS #7580

jacobmarshmallow opened this issue Sep 9, 2024 · 4 comments
Labels

Comments

@jacobmarshmallow
Copy link

Hi, now that Spring Boot supports it [1] [2] we were hoping to use java CDS to speed up our application start times.
In local testing we saw that it improved them drastically but when we went to run it in the cloud with the datadog agent attached we could see from the class loader + class path logs (-Xlog:class+load:file and -Xlog:class+path=debug:file) that the classes were being loaded from the jars again and not the .jsa archive we generated. I'm not actually sure if it's even technically possible, but it would be great if the agent could support loading the apps classes it needs from the archive. I am happy to provide a reproduction if necessary

@mcculls
Copy link
Contributor

mcculls commented Sep 9, 2024

Hi @jacobmarshmallow - thanks, a reproduction would be very helpful

Note we are limited to what the JVM instrumentation API lets us do and how that interacts with shared classes.

@jacobmarshmallow
Copy link
Author

Hi @mcculls,
Here is a repro repo, I hope it helps!

Yeah I am hoping the JVM allows for it, I am at the limits of my knowledge around agents so was just raising to with the hope that it might.

@Wikiko
Copy link

Wikiko commented Oct 1, 2024

I'm having the same trouble :/

@robertocomo
Copy link

robertocomo commented Jan 3, 2025

Hi. @mcculls the issue with not being able to use CDS with the DataDog agent is that CDS requires that the classpath must be the same as the one used to create the archive. The DataDog agent loaded with the -javaagent parameter injects new classes in the classpath breaking CDS support.

This behaviour can be spotted by the startup warning log OpenJDK 64-Bit Server VM sharing is only supported for boot loader classes and looking at the class loaded -Xlog:class+load=info file with a few source: shared objects file and instead a lot of entries that report a source location.

I tried to create a static archive of shared classes injecting also the DataDog agent, and then using the static archive to generate the shared .jsa archive:

java -Xshare:off -XX:DumpLoadedClassList=./class-list.classlist -Dspring.context.exit=onRefresh -javaagent:./datadog-apm-agent/dd-java-agent.jar -jar webapp.jar
java -XX:ArchiveClassesAtExit=./webapp.jsa -XX:SharedClassListFile=./class-list.classlist -Xlog:cds=debug:file=./webapp_cds-classlist.log -Dspring.context.exit=onRefresh -jar webapp.jar

but it did not work anyway.

Looking at CDS documentation:

When using the archive, the classpath must be the same than the one used to create the archive, in the same order. Additional JARs or directories can be specified at the end (but won’t be cached).

the point is that the classpath could be modified, but only keeping the same order of the classpath used to generate the archive and append any new class definitions at the end.

This is something addressed also by other projects, see: GoogleContainerTools/jib#2471

Do you think it would be possible to figure out how to load the DataDog agent by injecting the modified classpath at the end of the class list definition, preserving CDS compatibility?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants