-
Notifications
You must be signed in to change notification settings - Fork 323
Description
Tracer Version(s)
1.53.0
Java Version(s)
24, 25
JVM Vendor
Oracle JDK
Bug Report
Hello, I am not sure if this is an issue or not, but I figured starting a conversation would be nice.
In modern JVM applications, specially under distributed systems architecture, multi releases per day are very common, the performance impact of cold JVM affects the latency and throughout of JVM applications in a catastrophic way.
Project Leyden aims to alleviate this issue, specifically AOT Cache, see:
JEP 483: Ahead-of-Time Class Loading & Linking
JEP 514: Ahead-of-Time Command-Line Ergonomics
The dd-trace-java is a fantastic piece of software that allows automatic instrumentation of handful of jvm libraries, unfortunately, applications using it can't try AOT caching.
This is expected, the JEP 483, specifies that training and subsequent runs should NOT use agents:
All runs must have consistent module options on the command line, and consistent module graphs. The arguments to the -m, --module, -p, --module-path, --add-modules, and --enable-native-access options, if present, must be identical. The --add-exports, --add-opens, --add-reads, --illegal-native-access, --limit-modules, --patch-module, and --upgrade-module-path options must not be used.
All runs must not use JVMTI agents that can arbitrarily rewrite classfiles using ClassFileLoadHook.
All runs must not use JVMTI agents that call the AddToBootstrapClassLoaderSearch and
I would like to open a discussion to see what can be done here, I did some basic testing and applications using AOT cache are starting 50% faster and throughout behaves as if the JVM was already warmed up, giving peak performance right away during app startup.
Expected Behavior
I would love to be able to use AOT caching in apps using the dd-trace-java
Reproduction Code
No response