I use Eclipse Memory Analyzer, but tools only get you so far. You just have to understand very well how the machinery works :( That said in many cases EMA leak suspects will reveal the leaks right away.

I have a 100M+ EAR application that apparently leaks classloaders. So far I’ve been able to trace some of the live objects up to the static fields in one app class, but I can’t find out who leaks the classloader.

Thanks for the catch!

Yeah and I guess I am too practical. Truth is even if the spec is OK for that particular class JVMs implement the spec differently and I just wouldn’t risk with fine lines like that when it can lead to an error on some Sun JVM 1.4_07.

Thanks for the post!

I don’t mind at all. But let’s discuss this or other stuff further with some kind of beverage at hand :)

The only constraint it introduces is: Holder.class.getClass().classLoader().loadClass(“java.util.ArrayList”) == this.getClass().classLoader().loadClass(“java.util.ArrayList”);

which it is … you cannot disagree with it since it is not a beauty thing, you can disagree only if you find a counter example, which I believe is you cannot do (but would love to see one).

If “defining same named class in non-sibling class loaders is not allowed”, I guess it would say so in the spec, wouldn’t it?

(It actually does introduce more constrains, namely on Class and String and likely some more … since Object introduces those)

As a matter of fact, you can easily create a fun ClassCastException:

Holder x = (Holder) loadedHolder.newInstance();

It says: cannot cast Holder to Holder … yay!

—

I understand you were trying to fix a classloader leak, but the underlying cause for the leak is more general, and cannot be fixed in the Observable implementation, since you cannot generally know the target of a Listener and ‘fix a strong reference’ (If you could, java would have a fourth Reference type: the BoundReference; as long as that thing is alive, keep the target of the BoundReference alive.)

Only in this specific case we can, since we don’t fix it to the target, but to the classloader of both Listener and target. And in this case, that is good enough.

It can be fixed in general, however, if we modify the expectations of Observable slightly: namely registering something to Observable does not introduce strong a reference to that something.

(But again, I do understand that likely this is useless to you, since in the real world, you have real Observable’s and their semantics cannot be changed anymore… and because of that, your proposed solution is actually quite nice.)

Well, love to see a counter example, but otherwise I’ll stop harassing you :) hope you didn’t mind …

I was trying to solve a particular problem of class loader leaking in Java EE, not every memory leak in the Java language. The example you bring doesn’t involve any class loaders and isn’t relevant :)

1. It does not violate the spec, since the last two of the four condition for link failure are not met.

2. My solution does not depend on loadClass at all, only defineClass, which is a final method and cannot be overridden (and after a check is a native method). So it absolutely does not matter what any classloader subclass does.

You are right about the leak though, sorry. We should weak reference the ArrayLists as well in our holders map, or we still hold strong refs to the classloader.

Honestly, both solutions are quite similar, just mine is half the lines of code, because it does not customize the class, and does not implement some kind of classloaderlocals map. But maybe that last one is useful?

—

But I must restate that this is not a good solution at all. Because this problem is not related to classloading, just classloading makes it worse since it fills up permgen.

Imagine a heavyweight view in a GUI app that registers observers, but fails deregister them; after opening that view lots of time, the vm has a lot of objects that are still reachable through observable->listener->target, worse, they still get signals and process them. But these objects will never do anything visible, they belong to long ago removed views.

Only a WeakObservable is a real solution. Slightly more difficult as the regular Observable, since you must ensure to strongly hold on to the listeners you give it.

However, you will quickly see a bug appear around views not receiving signals even after you have register them … and bugs programmers can fix. Memory leaks are much harder to find and fix.

good discussion indeed :)

-Onne

Spec says it’s not allowed http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#78621 and loadClass() is overridden by almost any custom class loader in a variety of ways. Good luck with that, I had enough fun debugging such errors for a lifetime…

Also the “working” code you proposed leaks class loaders, since holders has strong references to listeners that hold the classes that hold the class loaders.

Read/Write lock might be a good idea, though. Thanks for the discussion!