dd-trace-java icon indicating copy to clipboard operation
dd-trace-java copied to clipboard

Support CDS

Open jacobmarshmallow opened this issue 1 year ago • 8 comments

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

jacobmarshmallow avatar Sep 09 '24 11:09 jacobmarshmallow

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.

mcculls avatar Sep 09 '24 12:09 mcculls

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.

jacobmarshmallow avatar Sep 09 '24 14:09 jacobmarshmallow

I'm having the same trouble :/

Wikiko avatar Oct 01 '24 12:10 Wikiko

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: https://github.com/GoogleContainerTools/jib/issues/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?

robertocomo avatar Jan 03 '25 14:01 robertocomo

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

AlvaroRCAbreu avatar Mar 05 '25 12:03 AlvaroRCAbreu

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

mmvaubrun avatar Apr 23 '25 13:04 mmvaubrun

Also upvoting for supporting CDS 🙏

sylvaincombes avatar Oct 17 '25 14:10 sylvaincombes