スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
ブログランキングに参加しています。応援クリックいただけると嬉しいです♪
FC2ブログランキング
人気ブログランキングへ

Automated memory leak detection tool for plugin environments

NOTE: This is the English translation of the article that I wrote in Japanese here.

Our team is developing a system that has a plugin architecture, kind of like Eclipse. Each plugin that is loaded has its own ClassLoader.

If that plugin is uninstalled and the plugin's classloader cannot be garbage collected, then there is a memory leak. Failure to garbage collect a plugin's classloader can be caused by a dangling reference to any single object loaded by that classloader or the classloader itself. As a result, debugging the cause of this can be very time consuming and difficult to figure out.

It would be nice to have a tool to tell us when this type of memory leak has been introduced. One way the tool would work would be to unload that plugin and check to see if that plugin's classloader is still in memory. So the question is, how do we create such a tool? Then, how can we leverage it in order to minimize the pain of debugging the memory leak?

CREATING THE TOOL:

There are a few options out there for looking for memory leaks. However, we'd like to pick the right one.

Using a tool like JProfiler isn't quite right, since we want to write an automated tool for this.

Using programmatic tools for performing heap dumps (like JVMTI) are a little too heavy, since we
have to deal with loading and reading very large files.

What would be nice is to have a tool which scans memory looking for the objects we're interested in. Enter Insane, which has an API that will allow us to do exactly that. Insane will allow us to write a tool that will scan the JVM heap for any hard references to plugin classloaders.

HOW TO USE THE TOOL:

With the tool described above, it should be possible to write a test which shuts down a plugin and then checks if the plugin's classloader is still in memory. If so, then there is a memory leak as previously mentioned.

You can then have a continuous integration tool like CruiseControl run that tool every time a change is committed to the source code. If done, the tool will run every time a change is made to the system.

In the case the test fails, you'll be able to quickly narrow down the set of changes that caused the leak, This will especially be the case if you're using a tool like CruiseControl which lists the code changes that could have caused the failure!

From there, you have a few options, depending on your development process:

* If the set changes is small, developers can quickly code review the changes that caused the leak.
* Someone can use a profiling tool like JProfiler to diagnose the memory leak.
* For the sake of product stability, the changes can be reverted in order to get rid of whatever caused the leak. Then, a developer can fix the leak on his local machine and then re-introduced the changes plus the fix.

How to obtain the Insane library

1. Go to the following site to download the zip file:
http://updates.netbeans.org/netbeans/updates/6.0/uc/final/beta/modules/org-netbeans-insane.nbm
(When you use Firefox, you'll notice that the file extension is .nbm. Save the file as it is and change the file extension to .zip. When you are using IE, the file extension is .zip.)

2. You will find the file named "org-netbeans-insane.jar" in the netbeans/modules/ folder.

3. The following website shows how to use the insane library: http://performance.netbeans.org/insane/

4. The main class you will want to look at is ScannerUtils.java, and DemoScanner.java shows you how you can utilize ScannerUtils.java.


ブログランキングに参加しています。応援クリックいただけると嬉しいです♪
FC2ブログランキング
人気ブログランキングへ

COMMENTS

COMMENT FORM

TRACKBACK


この記事にトラックバックする(FC2ブログユーザー)

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。