if you look at  "/core-service=platform-mbean/type=memory-manager/name=G1_Concurrent_GC:read-resource(include-runtime"

You can see the ObjectName "java.lang:type=MemoryManager,name=G1 Concurrent GC".

This ObjectName doesn't exist, it has been built by the WildFly Management Model.

The root cause of why the GC are exposed as MemoryManager is that, implementation wise, the GarbageCollector MXBeans are implementing the MemoryManagerMXbean interface. So calling ManagementFactory.getMemoryManagerMXBeans() will also return the GarbageCollector.

We can fix the ObjectName by, instead of computing it, use the ObjectName of the actual MXBean.

BTW, it could apply to all resource that have named children: GarbageCollector, BufferPool and MemoryManager.

bstansbe@redhat.com , I am also wandering if exposing the GC as MemoryManager in the Management Model is correct? It seems that we want to reflect the JMX Management model, the GC are not of type MemoryManager, so they should be filtered-out when building the children resources. This filtering based on the type should be applied to other resources that callManagementFactory.getXXXMXBean to retrieve the children.