MBean server error building native

[galderz]

With Mandrel 20.2 branch and Quarkus master:

Detailed message:
Error: Detected a MBean server in the image heap. This is currently not supported, but could be changed in the future. Management beans are registered in many global caches that would need to be cleared and properly re-built at image build time. Class of disallowed object: com.sun.jmx.mbeanserver.JmxMBeanServer  To see how this object got instantiated use -H:+TraceClassInitialization. The object was probably created by a class initializer and is reachable from a static field. You can request class initialization at image run time by using the option --initialize-at-run-time=<class-name>. Or you can write your own initialization methods and call them explicitly from your main entry point.
Trace: Object was reached by
	reading field com.sun.jmx.mbeanserver.MXBeanLookup.mbsc of
		constant com.sun.jmx.mbeanserver.MXBeanLookup@e5f96f7 reached by
	reading field java.lang.ref.Reference.referent of
		constant java.lang.ref.WeakReference@13ca094e reached by
	reading field java.util.HashMap$Node.value of
		constant java.util.HashMap$Node@63c8a982 reached by
	indexing into array
		constant java.util.HashMap$Node[]@331d11e5 reached by
	reading field java.util.HashMap.table of
		constant java.util.HashMap@3f62a453 reached by
	reading field com.sun.jmx.mbeanserver.WeakIdentityHashMap.map of
		constant com.sun.jmx.mbeanserver.WeakIdentityHashMap@22403af7 reached by
	scanning method [email protected]/com.sun.jmx.mbeanserver.MXBeanLookup.lookupFor(MXBeanLookup.java:93)
Call path from entry point to com.sun.jmx.mbeanserver.MXBeanLookup.lookupFor(MBeanServerConnection):
	at [email protected]/com.sun.jmx.mbeanserver.MXBeanLookup.lookupFor(MXBeanLookup.java:93)
	at [email protected]/com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:159)
	at [email protected]/com.sun.jmx.mbeanserver.MBeanSupport.preRegister2(MBeanSupport.java:173)
	at [email protected]/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:919)
	at [email protected]/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
	at [email protected]/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
	at [email protected]/com.sun.jmx.mbeanserver.JmxMBeanServer$2.run(JmxMBeanServer.java:1225)
	at app//com.oracle.svm.core.jdk.Target_java_security_AccessController.doPrivileged(SecuritySubstitutions.java:119)
	at [email protected]/java.net.Socket.getOutputStream(Socket.java:969)
	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:214)
	at [email protected]/java.io.PrintStream.flush(PrintStream.java:417)
	at app//com.oracle.svm.jni.functions.JNIFunctions.ExceptionDescribe(JNIFunctions.java:772)
	at com.oracle.svm.core.code.IsolateEnterStub.JNIFunctions_ExceptionDescribe_b5412f7570bccae90b000bc37855f00408b2ad73(generated:0)

Longer output

[galderz]

Assigned this to myself.

[galderz]

New restrictions added as part of oracle/graal@8d6a41b77a0 and oracle/graal@72d244caf8e. Similar problems have been reported (see oracle/graal#2669).

Looking at the analysis, I see RemoteCache* having call paths to the platform server which have not been cut off, e.g.

│   │       │   │           ├── directly calls org.infinispan.client.hotrod.RemoteCacheManager.unregisterMBean():void id=31682 @bci=125 
...
│   │       │   │       │   │   │       ├── directly calls org.infinispan.client.hotrod.RemoteCacheManager.registerMBean():void id=69231 @bci=123 

I'll try to substitute those methods to empty impls and see if that helps.