<div dir="ltr">Hi all,<br><br>Serviceability has been one of the biggest Java strengths, but the proposed change is going to have a large negative impact on it.<br><br>Disallowing dynamic agents by default means it will no longer be possible to attach a profiler to a running app in runtime. JFR cannot close this gap due to lack of capabilities modern Java profilers have (that's a separate topic though).<br><br>When an issue happens with a live app, it's already too late to add a command line argument. Furthermore, it may not be even feasible to add an agent at startup in containerized applications. Starting profiler on demand from the host OS or from a sidecar is the only viable solution in these cases.<br><br>Next, it's hard to predict beforehand what tools exactly might be useful for troubleshooting: e.g., one tool may be better for finding memory leaks, a different one for analyzing CPU performance. Adding all possible tools at startup does not seem a reasonable approach, especially when tools may conflict with each other.<br><br>The most important aspect of dynamic agents is the possibility to make a special tool just in time for solving a particular problem. A typical example is to get a value of some field in a live app without dumping the entire 60 GB heap. Another common use case is hot patching for fixing trivial bugs or for adding debug logs dynamically. The prominent example is when the dynamic agent has proved irreplaceable aid in addressing the notorious log4j vulnerabilities CVE-2021-44228 and CVE-2021-45046.<br><br>I would be grateful to know more about the reasons why we should give up all the above advantages of dynamic agents in their good and legitimate use cases.<br><br>Thank you,<br>Andrei<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 16 мар. 2023 г. в 18:48, Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi.<br>
<br>
In JDK 21 we intend to disallow the dynamic loading of agents by default. This<br>
will affect tools that use the Attach API to load an agent into a JVM some time<br>
after the JVM has started [1]. There is no change to any of the mechanisms that<br>
load an agent at JVM startup (-javaagent/-agentlib on the command line or the<br>
Launcher-Agent-Class attribute in the main JAR's manifest).<br>
<br>
This change in default behavior was proposed in 2017 as part of JEP 261 [2][3]. <br>
At that time the consensus was to switch to this default not in JDK 9 but in a <br>
later release to give tool maintainers sufficient time to inform their users. <br>
To allow the dynamic loading of agents, users will need to specify <br>
-XX:+EnableDynamicAgentLoading on the command line.<br>
<br>
I'll post a draft JEP for review shortly.<br>
<br>
-- Ron<br>
<br>
[1]: <a href="https://docs.oracle.com/en/java/javase/19/docs/api/jdk.attach/com/sun/tools/attach/package-summary.html" rel="noreferrer" target="_blank">https://docs.oracle.com/en/java/javase/19/docs/api/jdk.attach/com/sun/tools/attach/package-summary.html</a><br>
[2]: <a href="https://openjdk.org/jeps/261" rel="noreferrer" target="_blank">https://openjdk.org/jeps/261</a><br>
[3]: <a href="https://mail.openjdk.org/pipermail/jigsaw-dev/2017-April/012040.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/jigsaw-dev/2017-April/012040.html</a></blockquote></div>