RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature [v3]

[Daniel Fuchs]

On Thu, 11 Jan 2024 11:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yes, that's the whole point of the test. Without using an MBean which is a ClassLoader the fix cannot be tested.
>> 1. you need to create an MBean which is an URLClassLoader, and it needs to be a PrivateClassLoader so that it's not added to the ClassLoaderRepository - let's call it  LoaderMBean.
>> 2. you need to use that LoaderMBean to load another MBean - let's call it TestMBean. The concrete class of TestMBean needs to be loaded by the LoaderMBean - that is - LoaderMBean needs to be the defining ClassLoader for that class (the TestMBean class must not be loaded by the System/Application ClassLoader).
>> 3. In the MBeanServer you then end up with two MBeans, one is the LoaderMBean, the other is the TestMBean whose class has been loaded by the LoaderMBean.
>> 4. you then keep a weak reference on the _LoaderMBean_, and unregister both MBeans.
>> 5. at that point - if the Introspector still has a strong reference to the class of the TestMBean, then the _LoaderMBean WeakReference_ will never be enqueued, because the class of the TestMBean will have a strong reference to its ClassLoader, which is _LoaderMBean_.
>> 
>> So you can only test that if you have an MBean which is loaded by a custom ClassLoader, because you want to verify that the Introspector doesn't hold on that ClassLoader (through the TestMBean class).
>
> Hi Daniel -
> I am missing see how being a ClassLoader relates to the leak where the Introspector holds on to a reference to the most recent MBean.  I didn't locate the jdk5 change, I only read a short synopsis.
> 
> I can make this test create an MBean which is a ClassLoader, and the test can do its check that having the loader MBean load a class, creates a distinct class.  I can add that update here.  But it looks like an MLet test which leaked into the Introspector test. 8-)

Hi Kevin,

To verify whether the Introspector holds a reference to a *Class Object* you need that class to be loaded by a custom class loader, and verify that the custom class loader that loaded that class can be garbage collected.

If the class loader that loaded that class has not been garbage collected after you released all references to it, then it's because the class it loaded is still referenced somewhere.

The logic of the test is as follows:
You create an MBean L which is a class loader and able to load class C. L must be the defining class loader for C.
You register L in the MBeanServer.
You ask the MBeanServer to create an MBean of class C through L (this is why you must use the variant of createMBean that takes a loader name).
You keep a weak ref to L
You unregister L and the MBean of class C from the MBeanServer and make sure the test doesn't have any strong reference to them (or to class C).
Then you start GC and wait until the weak ref to L is enqueued. If that doesn't happen, it's because the Introspector still hold a reference to class C.

You cannot test that if C has been loaded by the system class loader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1448772336