On Thu, 11 Jan 2024 12:23:37 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> 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. I am updating those two tests. I read the test as checking that an Object instance is collected, rather than Class Object, so was favouring making it simpler. But we can use an MBean which is a URLClassLoader, and things will be more similar to the originals. Some of MXBeanLoadingTest1 is duplicating some of ClassLeakTest, so something for future auditing perhaps... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1449391121
