Support CDS

[jacobmarshmallow]

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]

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]

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]

I'm having the same trouble :/

[robertocomo]

Hi. @mcculls the issue about 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 also 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?

[AlvaroRCAbreu]

I have the same issue. Is there any news about it?

[mmvaubrun]

Any news about this ? With CDS integration coming out of the box with Spring Boot it would be supper cool that the dd-agent support it as well

[sylvaincombes]

Also upvoting for supporting CDS 🙏

[mcculls]

👋 we've added a feature in #10166 that supports using -javaagent:dd-java-agent.jar during both AOT training and production on Java 25+

This feature is part of the v1.57.0 release expected this week.

During training you can now use:

-XX:AOTCacheOutput=my-app.aot -javaagent:dd-java-agent-1.57.0.jar

During production use:

-XX:AOTCache=my-app.aot -javaagent:dd-java-agent-1.57.0.jar

This targets the AOT class-loading+linking feature from https://openjdk.org/jeps/483 rather than the older CDS approach, because we've found AOT provides much better startup savings when using APM.