Java Interactive Profiler

Hello !

I am currently developing an eclipse feature (set of plugins).
In order to improve speed performance, I need to profile these plugins.
Basically, this profiling consists in analyzing cpu consumption or execution time per method.

The difficulty with eclipse is that plugins class loader is dynamically loaded thus not loaded by the JVM when JIP starts.
This results in a UNKNOWN CLASSLOADER error.

I have seen some similar posts but did not manage to solve this problem.

Please can someone help ?

Thanks ahead,
Thomas.

Hi Thomas,

As you observed, GenericClassLoaderFilter doesn't work well when the ClassLoader you're targeting is dynamically loaded. The way around this is to create your own ClassLoaderFilter, which is pretty straightforward:

package FOO.BAR;
public class EclipsePluginLoaderFilter implements ClassLoaderFilter {

public boolean canFilter() {
return true;
}

public boolean accept(ClassLoader loader) {
return loader.getClass().getName().equals( "<CLASSLOADER - NAME - HERE>" );
}
}

Then in your profile properties:

ClassLoaderFilter.1=FOO.BAR.EclipsePluginLoaderFilter

and remember to remove

accept-class-loaders=...

If you post the name of the classloader to this forum, I'll add the appropriate ClassLoaderFilter to the next release of JIP.

Thanks!

Andrew.

Andrew,

Thanks for your help,
Unfortunately, I will not be able to try this before a couple of weeks.
But I will write my own ClassLoaderFilter when I am back to my office and then post the result on that forum.

Thomas.

Hi Andrew !

Sorry for the late answer but I did not work on this topic until now.

The default class loader in eclipse is org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader

Thanks
Thomas

Hello Andrew,

I have created a ClassLoaderFilter as you mentionned,
unfortunately, I get the following error:
Could not instantiate ClassLoaderFilter EclipsePluginLoaderFilter
although I add the class to the classpath of the JVM.

Please could you help ?

Thanks ahead,
Thomas

Hi Thomas,

You're doing the right thing, so I'm not sure why it's no working. Here are some things to try:

In your profile.properties file, make sure that you're specifying the full class name (including the package) of your filter. I.e., ClassLoaderFilter.1=mypackage.EclipsePluginLoaderFilter

Specify the path to your filter in JVM's classpath as absolute, rather than relative. Relative paths can be problematic, since the JVM doesn't always start in the directory that you think it does.

Move the path to your filter to the beginning of the JVM classpath. JVM's generally stop using subsequent classpath entries once they encounter a path that's invalid. If there are any issues with the path you're using, Eclipse will bomb because it can't load any of the other entries in the classpath.

Andrew.

Andrew,

I omitted one important element: I am launching eclipse from an ant script.
The class path was not set properly.

Now that it is set properly, the profiled classloader are not org/eclipse/equinox/launcher anymore
but the plugins loaded by the class loader allowed by my custom filter (I can check with debug = on).

Then I get the following error when launching eclipse :

[java] Controller -- shuttingdown
Java Result: 13

I tried to run the java command from a DOS shell and got the same result, so the problem does not seem to be related with ant.

Thanks for your help,
Thomas

After having enabled eclipse -consolelog option,
I got the following :
[java] Caused by: java.lang.ClassNotFoundException: com.mentorgen.tools.profile.runtime.Profile

Hi,

Actually, to be more precise,
I try to profile eclipse plug-ins running within a runtime workbench.

It seems that the problem is that the runtime profiler is loaded by the application class loader while the classes I expect to profile are loaded by a specific class loader related to the OSGI Platform. Thus the byte code injected into the profiled classes introduces a dependency on the profiler that cannot be resolved.

So my question - that may be addressed to eclipse experts - is :
Is it possible to resolve this dependency in order to make the profiler work in this kind of configuration, which I guess would have a great success.

(I know this can be done thanks to the keyword Eclipse-BuddyPolicy in the plugin manifest on plugins that can be modified. Unfortunately, to make it work, this change has to be done on most of the plugins of the workbench).

Thanks,
Thomas

Hi,

I made the following test:
Added the statement:
Eclipse-BuddyPolicy: app
to the first plugin causing this issue.

Run again, the exception raises on the next plugin.

So this confirms this issue.

Thanks,
Thomas

Hi Thomas,

Profile.jar needs to be loaded by the Application classloader. The classes you want to profile may be loaded by a child classloader, but that should be ok.

JIP has 3 different phases:
1) Instrument
2) Profile
3) Output

In the Instrument phase, JIP has the ability to instrument any class, regardless of which classloader is loading it. During this phase, classes are instrumented to call the Profile class, which is assumed to be loaded by the Application Classloader, since this is how the javaagent interface works. If you see this exception:

java.lang.ClassNotFoundException: com.mentorgen.tools.profile.runtime.Profile

there are a couple of things to look at:

1) make sure that profile.jar is being loaded by the application classloader.
2) this is a kludge, but you might try putting another copy of profile.jar in the classpath for your plugin.

I want to make sure we can get this problem solved, so please let me know how things go.

Regards,

Andrew.

Hi Andrew,

Actually, the problem is that the classes of most of the plugins (probably all the plugins) are loaded by "org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader".

And because of eclipse class loading policy, this classloader is different from the application class loader (actually, I do not know what is the relation between them).

As an answer to (2), the problem is that not only my plugin cannot access to profile.jar but all the classes loaded by org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader, which are eclipse classes that I cannot change.

In order to make it work, the instrumented classes must have access to the classes loaded by the ApplicationClassLoader (here profile.jar) and I do not know how to do that in this context.

Could it be resolved with a call to findSystemClass or findLoadedClass from instrumented classes or classloader ?

Thanks,
Thomas

Hi Andrew,

I got around the above exception (ClassNotFoundException: com.mentorgen.tools.profile.runtime.Profile) by creating a plugin from the profile.jar so that all the plugins I want to profile can have access to it. I also added a class loader filter that will allows the plugins loaded by "org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader" to be profiled.

But I got into another problem:

java.lang.NullPointerException
at com.mentorgen.tools.profile.runtime.Profile.alloc(Profile.java:378)

This happens when the instrumented classes try to call methods of the "now" accessible Profile class. It appears that, while trying to have another copy of the Profile.jar, either by adding it to the classpath of a plugin, or have it as a plugin too, the only initialized Profile class is the one that has been loaded by the application loader, the second copy which is not being initialized and that is the reason of the null pointer exceptions.

I going to keep one copy of the Profile.jar, the one configured at the JVM start up, and try to have access to it by calling findLoadedClass ....from the plugins to be profiled....

Any thoughts?

Thanks.

Hi Thomas,

Having loading two copies of profile.jar doesn't seem like it was a good idea. Sorry for suggesting that.

After doing some research, I suspect that "Eclipse-BuddyPolicy: app" is probably the only solution. I realise that this causes down-stream issues, i.e. this policy will need to be added to other plugins, but given Eclipse's classloading system and the fact that javaagents are loaded by the application classloader, I don't see another way of making this work.

Andrew.

hi Andrew and Thomas.
After reading your discussions above I understand reasons for the problems I met when profiling Eclipse-plugin project, however i am still puzzled about the way to solve this problem, would you please conclude the solutions to it? thank you

davy