YourKit Object Explorer Object Value

[amitmondal]

According to the documentation, few object values are shown directly in YourKit object explorer.

I am currently profiling an application but couldn't understand so far what the object (org.apache.felix.framework.BundleWiringImpl$BundleClassLoader) value (in parantheses) as shown in the enclosed image denotes and how it is calculated.



I would really appreciate further assistance in this regard.

Thanks in advance.

[Anton Katilin]

Hello,

org.apache.felix.framework.BundleWiringImpl$BundleClassLoader instances are class loader objects i.e. the class extends java.lang.ClassLoader. Please note the icon with "L" which indicates class loader objects.

If there are 2 or more loaders of the same class, the profiler enumerates them to make them distinctive in the object explorer. Each loader is assigned a number, and you can see whether some objects belong to the same loader or to different ones, although of the same class. The numbers themselves are arbitrary, they just correspond to the order in which the profiler enumerated the loader objects inside the snapshot. Technically, this corresponds to internal object IDs, which, in turn, depend on the physical order of objects in the heap. In practice, treat this order as random, it may vary from snapshot to snapshot.

In your case, there are 306 such loaders. This means they must have been numbered from 1 to 306. No further conclusions regarding the numbers themselves should be made.

Best regards,
Anton

[amitmondal]

Hi Anton,

Thanks a lot for your quick response. Could you kindly tell me if there is any way to programmatically get an unique object ID which is also shown in YourKit? Actually I need to find a specific leaking classloader instance first programmatically and then pin point the same object in YourKit to find out what makes this instance retain in memory?

Thanks in advance,
Amit

[Anton Katilin]

Hello Amit,

Please consider persistent object IDs:
https://www.yourkit.com/docs/java/help/ ... ent_id.jsp

Best regards,
Anton

[Anton Katilin]

Hello Amit,

Update: in the next major version we'll also add an explicit API method to get the persistent ID for an object. The first Early Access Program (EAP) build will provide it.

Best regards,
Anton

[amitmondal]

Hi Anton,

Thanks a lot for the quick response. I am actually looking into introducing custom probes. Could you kindly tell me if I could contribute to the Inspections table as well? That is, if I can introduce custom table under Inspections to execute custom functionality.

Thanks in advance,
Amit

[Anton Katilin]

Hello Amit,

Inspections are not user-customizable. A custom table can be inspected in the "Events" tab.

What inspection would you like to apply to your custom table? What events do you plan to store and analyze? If what you're doing is interesting to a wide range of users, we might consider adding a new inspection or extending an existing one.

Best regards,
Anton

[amitmondal]

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 -

Bundle Symbolic Name

Bundle Version

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

[Anton Katilin]

Hello Amit,

Your suggestion to automate detection of leaked OSGi loaders sounds really interesting. Thank you for the detailed explanation.

If the fact whether an OSGi classloader corresponds to an installed bundle (is not a leak) or not (is a leak) can be determined by statically analyzing objects in a memory snapshot, e.g. if there is a list of current bundles somewhere in the framework internals which we can traverse to find out bundle properties (name, version) and corresponding legitimate loaders, we could solve the task without a probe.

The benefit of not using a probe is that the analysis would be possible for any memory snapshot, be it the profiler format .snapshot file or a .hprof file which does not contain any YourKit profiler specific information such as events recorded with probes. Also, probes should be always on; while off, they miss events. In particular, if a JVM instance started without the profiler agent is attached by the profiler, all events which have happened before the attach will obviously be missed.

We could associate "Bundle Symbolic Name" and "Bundle Version" with the classloader instance. It would appear wherever the loader is shown, e.g. in object explorers or in "Class loader" view ( https://www.yourkit.com/docs/java/help/ ... oaders.jsp ).

Leaked loader objects would be indicated too with corresponding text.

To simplify finding such loaders, a new memory inspection could be added to explicitly present the list of them.

As a workaround for the current UI, I think you can try the memory inspection "Classes with same name" which finds identically named classes in different loaders. If there is a leaked loader and a new loader corresponding to the same .jar, it's highly likely that the same classes will appear in both, and this will be detected by the inspection.

Best regards,
Anton

[amitmondal]

Hi Anton,

Thanks for your quick and enthusiastic response. Since you asked if there is any place where the list of bundles are stored, here is the link: https://github.com/apache/felix-dev/blob/69dfea9af1e74be43bf8733176c502b70509be4c/framework/src/main/java/org/apache/felix/framework/Felix.java#L160

This is the internal code of the most popular OSGi implementation - Apache Felix.

Apart from this, the following Javadoc would be useful to know how to retrieve the current classloader instance of a bundle.

https://docs.osgi.org/javadoc/r6/core/org/osgi/framework/wiring/BundleWiring.html

Since in OSGi, we can have similar bundles of different versions, there could be multiple bundles that load the classes with identical names (possibly comprising different methods). For example, let's say we have com.example.log bundle that has the following Logger API -

Code: Select all

public interface Logger {
   public void error(String var1);

   public void warn(String var1);

   public void info(String var1);

   public void debug(String var1);

   public void trace(String var1);
}


Now this resides in the com.example.logger.api package (version 1.0.0). Now there are other bundles that use this com.example.logger.api package version 1.0.0. Now one can install another bundle - com.example.log.v2 bundle that comprises the following API:

Code: Select all

public interface Logger {
   public void error(String var1);

   public void warn(String var1);

   public void info(String var1);

   public void debug(String var1);

   public void trace(String var1);

   public void error(String var1, Throwable var2); // new method
}


And this API resides in the same package (com.example.logger.api Version 2.0.0) but in different bundle (com.example.log.v2). Now there could be other consumer bundles that might use this package in the same runtime where com.example.logger.api Version 1.0.0 is used by some other consumers.

That means, there could be classloaders that load the classes of the same names but the APIs are different. That's why finding classes with identical names will not be very useful in OSGi environment.

If you need any further information, please don't hesitate to contact me.

Thanks and Regards,
Amit

[amitmondal]

Hi Anton,

Enclosed please find the hierarchy of the assocated classloader of any bundle instance.



Note that, when a bundle is installed and each time a bundle is updated, a new bundle revision of the bundle is created. Since a bundle update can change the entries in a bundle, different bundle wirings for the same bundle can be associated with different bundle revisions.

But the current bundle revision for a bundle is always the first entry in m_revisions.

I hope it helps.

Thanks and Regards,
Amit

[amitmondal]

Hi Anton,

Please find the attached screenshot for further information on finding the associated bundle classloader.



Best Regards,
Amit

[Anton Katilin]

Hello Amit,

Thank you very much for this information. It's really helpful.

We would appreciate a lot if you could also share with us an example of a memory snapshot which demonstrates the problem, i.e. contains both legal and leaked loaders. It would help us much in starting working on the proposed functionality. Could you please compress the file with zip or any other similar tool and send the download link to [email protected]

Best regards,
Anton

[amitmondal]

Hi Anton,

I have sent you a mail comprising all the necessary snapshots. Should you require any further information, please feel free to contact me.

Thanks and Regards,
Amit

[amitmondal]

Hi Anton,

To retrieve the bundle symbolic name and the version of any bundle, please refer to the following screenshots:




If you require any further information, let me know.

Best Regards,
Amit