NotCompliantMBeanException during cache creation

[Gunnar Morling]

Hey all,

I've written a quick blog post about my experiences with JEP 483:

    https://www.morling.dev/blog/jep-483-aot-class-loading-linking/

Observing a reduction of 59% of start-up time for Apache Kafka and of 51%
of time-to-first-message for a simple Apache Flink job, very nice!

Best,

--Gunnar



On Tue, 25 Mar 2025 at 17:18, Gunnar Morling <gunnar.morling at googlemail.com>
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/20250328/5a2c43d1/attachment.htm>