Hi Anton,
Thanks a lot for your continuous support. I also wanted to discuss this with you if it is possible to introduce a general-purpose inspection. Let me first give you an overview of what I thought about it.
I have recently started using YourKit in OSGi runtimes. OSGi specifications define a standardized, component-oriented, computing environment for networked services that are the foundation of an enhanced service-oriented architecture. Any application can benefit from OSGi that is designed in a modular fashion where it is necessary to start, stop, update individual modules with minimal impact on other modules. Modules can define their own transitive dependencies without the need to resolve these dependencies at the container level.
Key features of OSGi are:
- Modularity - it is realized with the bundle concept;
- Runtime Dynamics - software components can be managed at runtime;
- Service Orientation - components communicate with each other through services.
In OSGi, a single component is called a
bundle. Logically, a bundle is a piece of functionality that has an independent lifecycle – which means it can be started, stopped and removed independently. Technically, a bundle is just a jar file with a
MANIFEST.MF file containing some OSGi-specific headers. The OSGi platform provides a way to receive notifications about bundles becoming available or when they're removed from the platform. This will allow a properly designed client to keep working, maybe with degraded functionality, even when a service it depends on, is momentarily unavailable.
Since every component (aka bundle) has its own lifecycle, if the used resources are not cleaned properly, this leads to classloader leaks. Every bundle associates a single classloader to load classes and resources. Once the bundle is updated in the runtime, it would have new classloader instance, but the previous classloader instance should be eligible for garbage collection or weak/softly reachable. But due to bad programming practice, sometimes the previous classloader stays strongly reachable from the GC root.
It is quite common in OSGi runtimes and hence a big challenge to profile an OSGi application. Since in an OSGi runtime, there can exist thousands of bundles (jars) to interact with each other, there can be thousands of different classloaders. And every time, a bundle is updated, we have to make sure that it doesn't introduce any such classloader leak. Finding such an anomalous classloader which is still strongly reachable but not associated with any currently installed bundles is difficult during profiling. Currently, I need to look into all the existing bundle classloader instances and find out the one that belongs to a bundle. However, it is still not enough since there could be two or more classloader instances that load the same type of classes, but only one of them is the currently active classloader of the bundle.
My idea is to introduce two tables that contain the following:
-
Current OSGi Classloaders Instances TABLE -
Current Classloader Object Instance
-
Anomalous Classloader Instances TABLE -
Classloader Object Instance
The first table is used for informational purposes to list all the active classloader instances of all the installed bundles. In contrast, the second one contains all the classloader instances which are not associated with any of the installed bundles.
This would enable OSGi developers to profile any OSGi application for classloader leaks pretty quickly. Such an extension in YourKit would be an added benefit too. If it sounds a good fit, don't hesitate to contact me. I would be happy to provide further information if required.
Thanks in advance,
Amit