NotCompliantMBeanException during cache creation

[Calvin Cheung]

Hi Gunnar,

I couldn't reproduce the issue you described with the following simple test:

> 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

Do you have a simple reproducer?

Thanks,

Calvin

On 3/25/25 9:18 AM, Gunnar Morling wrote:
> Hey all,
>
> 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:
>
>     -Dcom.sun.management.jmxremote=true 
> -Dcom.sun.management.jmxremote.authenticate=false 
> -Dcom.sun.management.jmxremote.ssl=false
>
> 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:
>
>     -Dcom.sun.management.jmxremote=false
>
> 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.
>
> 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!
>
> Best,
>
> --Gunnar
>
>
>
> On Tue, 18 Mar 2025 at 05:40, <ioi.lam at oracle.com> wrote:
>
>
>     On 3/16/25 1:09 AM, Alan Bateman wrote:
>     > On 16/03/2025 02:12, ioi.lam at oracle.com wrote:
>     >> Could you send the exact command-line that causes the error? If
>     you
>     >> can share a self-contain reproducible test case, that would be
>     great!
>     >>
>     >> Looking from the stack trace:
>     >>
>     >>     at
>     >>
>     jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:542)
>     >>     at
>     >>
>     jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:316)
>     >>     at
>     >>
>     jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:448)
>     >>     at
>     >>
>     jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:601)
>     >>
>     >> It looks like you might have specified a Java agent in the "java
>     >> -XX:AOTMode=create ...." command line. Can you try removing
>     that and
>     >> see if it works?
>     >
>     > I assume it's something started with -Dcom.sun.management=... to
>     start
>     > the JMX agent. This sets in motion the registration of management
>     > beans and the JMX introspector machinery that looks at
>     annotations and
>     > causes Proxy classes to be generated into dynamic modules.
>     >
>     > Ioi - I suspect the restriction on creating dynamic modules in the
>     > dump phase may be too restrictive. The full module graph dumping
>     > should only be concerned with the boot layer.
>     >
>     > -Alan
>
>
>     Hi Alan, thanks for the information. I've created
>     https://bugs.openjdk.org/browse/JDK-8352187 to address this problem.
>
>     I verified that the dynamic modules created by the dynamic proxies
>     always have a null for its ModuleLayer. Also, there are no APIs for
>     adding new modules into the boot layer (after the boot layer has been
>     initialized), so the usage of ProxyBuilder.getDynamicModule()
>     shouldn't
>     cause problems for CDS.
>
>     https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/jdk/internal/module/Modules.java#L76-L82
>     https://github.com/openjdk/jdk/blob/38499b3fbfcd22252ddf860d42b9eb0bf6f77235/src/java.base/share/classes/java/lang/System.java#L2033-L2037
>
>     Thanks
>
>     - Ioi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250409/5e40ed49/attachment.htm>