On Tue, 25 Nov 2025 12:22:21 GMT, Alan Bateman <[email protected]> wrote:
>> src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java
>> line 192:
>>
>>> 190: HotSpotAOTCacheMXBean impl = this.impl;
>>> 191: if (impl == null) {
>>> 192: this.impl = impl = new
>>> HotSpotAOTCacheImpl(ManagementFactoryHelper.getVMManagement());
>>
>> This assignment is unusual. Are we trying to avoid a synchronized block?
>> Other nameToMBeanMap() methods are like:
>> return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME,
>> ManagementFactoryHelper.getMemoryMXBean());
>>
>> ..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized
>> and creates the impl if needed.
>
> I don't see a correctly issue with this. Maybe in the future we will be able
> to use LazyConstant here.
Sure, I'm just pointing out that we have a load of existing nameToMBeanMap()
methods that do things differently.
OK I now see this one is doing what the new VirtualThreadSchedulerMXBean did.
The others are different: commonly the nameToMBeanMap() methods in
PlatformMBeanProviderImpl.java are synchronized, or they call a getXXMXBean()
method which is synchronized.
Maybe these old methods don't need to be synchronized, if this all gets done at
startup in PlatformMBeanProviderImpl init(), the mbeans will always be created
once.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2564720463
