<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Gunnar,</p>
<p>I couldn't reproduce the issue you described with the following
simple test:<br>
<blockquote type="cite">java -XX:AOTMode=create
-XX:AOTConfiguration=hello.aotconfig -XX:AOTCache=hello.aot
-Xlog:cds -Dcom.sun.management.jmxagent=true
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -cp hello.jar</blockquote>
</p>
<p>Do you have a simple reproducer?</p>
<p>Thanks,</p>
<p>Calvin<br>
</p>
<div class="moz-cite-prefix">On 3/25/25 9:18 AM, Gunnar Morling
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CADGJaX8TWxz_DnCU9y3aBimnR5prtmpRkZTqz-vhKnt+=rtZ6Q@mail.gmail.com">
<div dir="ltr">
<div>Hey all,</div>
<div><br>
</div>
<div>Sorry for the late reply, I was travelling for a conference
last week. Indeed I had the following as part of my Java
invocation, as you suspected, Alan:</div>
<div><br>
</div>
<div> -Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false</div>
<div><br>
</div>
<div>It happens automatically from within Kafka's launch
scripts, which is why I hadn't noticed it at first. Once I
dropped that part, I could create the AOT cache file
successfully. Interestingly, the error still occurred when I
replaced the above with the following:<br>
<br>
-Dcom.sun.management.jmxremote=false</div>
<div><br>
</div>
<div>I'd have assumed this not to be the case? Similarly, I
tried to specify -XX:+UnlockDiagnosticVMOptions
-XX:+AllowArchivingWithJavaAgent to allow the cache creation
with an agent, but to no avail. The only way it did work was
by removing the three -Dcom.sun.management.* options
altogether.</div>
<div><br>
</div>
<div>I don't fully understand all the moving parts here yet, but
it appears as if the ergonomics of this feature could still be
improved? In any case, thanks a lot for your help, I was able
to create the AOT cache file in the end and it shaved off a
nice chunk of the Kafka start-up time!</div>
<div><br>
</div>
<div>Best,</div>
<div><br>
</div>
<div>--Gunnar</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, 18 Mar 2025 at 05:40,
<<a href="mailto:ioi.lam@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">ioi.lam@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 3/16/25 1:09 AM, Alan Bateman wrote:<br>
> On 16/03/2025 02:12, <a href="mailto:ioi.lam@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ioi.lam@oracle.com</a> wrote:<br>
>> Could you send the exact command-line that causes the
error? If you <br>
>> can share a self-contain reproducible test case, that
would be great!<br>
>><br>
>> Looking from the stack trace:<br>
>><br>
>> at <br>
>>
jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:542)<br>
>> at <br>
>>
jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:316)<br>
>> at <br>
>>
jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:448)<br>
>> at <br>
>>
jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:601)<br>
>><br>
>> It looks like you might have specified a Java agent
in the "java <br>
>> -XX:AOTMode=create ...." command line. Can you try
removing that and <br>
>> see if it works?<br>
><br>
> I assume it's something started with
-Dcom.sun.management=... to start <br>
> the JMX agent. This sets in motion the registration of
management <br>
> beans and the JMX introspector machinery that looks at
annotations and <br>
> causes Proxy classes to be generated into dynamic
modules.<br>
><br>
> Ioi - I suspect the restriction on creating dynamic
modules in the <br>
> dump phase may be too restrictive. The full module graph
dumping <br>
> should only be concerned with the boot layer.<br>
><br>
> -Alan<br>
<br>
<br>
Hi Alan, thanks for the information. I've created <br>
<a href="https://bugs.openjdk.org/browse/JDK-8352187" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8352187</a>
to address this problem.<br>
<br>
I verified that the dynamic modules created by the dynamic
proxies <br>
always have a null for its ModuleLayer. Also, there are no
APIs for <br>
adding new modules into the boot layer (after the boot layer
has been <br>
initialized), so the usage of ProxyBuilder.getDynamicModule()
shouldn't <br>
cause problems for CDS.<br>
<br>
<a href="https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/jdk/internal/module/Modules.java#L76-L82" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/jdk/internal/module/Modules.java#L76-L82</a><br>
<a href="https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/java/lang/System.java#L2033-L2037" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/java/lang/System.java#L2033-L2037</a><br>
<br>
Thanks<br>
<br>
- Ioi<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>