On 10/03/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > Java is a bit nasty in that it is difficult to "see" if during a OSGi UNLOAD > everything that should be unloaded from memory has been unloaded. > > Would it be possible to automate that??
Yes, it's possible to automate, but there would be some overhead. Although if you use a Java 5 VM then it's much better than earlier runtimes as it has the java.lang.management API and JVMTI. > For instance; if a 'management bundle' tracked which bundle export's which > packages, couldn't it make sure that all classes on the heap in those > packages are released from memory, and if not give some assistance in finding > out why not? A management bundle could listen for class (un)load events and detect when classes loaded for a particular bundle weren't unloaded - however, classes are only unloaded when their classloader is eligible for GC, and this only happens when it and *all* its classes are no longer referenced from GC roots (such as JNI stack frames, thread stacks, etc). Tracking down why a class (or object) is still referenced is harder than detecting leaks, as it involves scanning the reference tree and tracing from the roots (just like GC does) - then interpreting the graph. > Would we need to integrate it tightly into the framework? I don't think this would need really tight integration - mostly knowledge about classloader ownership and the import/export headers. This could be done in a framework agnostic way. > I realize that there are some tricky cases, as imports will be re-wired when > the exports disappear, and that one bundle that does not export its packages > may use those classes internally. We could quickly mock-up a simple agent and see how things go... > I guess Stuart is most qualified to give an educated guess on the complexity > of this, but everyone else; Does this make sense? Actually, we can build some really cool tools that show how much of the heap is tied to each bundle (by traversing the object graph) and help detect leaks in the lifecycle, etc. It's best to separate the GUI from the agent, so it can be hosted under Eclipse RCP, or appear as a standalone OSGi 'dashboard'. _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
