JBossProfiler: Beyond Finding Memory Leaks

Posted on 2006-06-11 00:08:59.0 by JBoss Profiler Team [ View original post ]

JBossProfiler: Beyond Finding Memory Leaks

Is there anyone on earth who actually likes chasing memory leaks?

I don’t think anyone does, and I can assure you that even with the most expensive and fanciest tool, it’s not a fun task to do.

Even after you have found and fixed a leakage, there still a question:

How can you ensure that you won’t have future leakages in your code? Are you willing to profile your application on every release?

How can you test for memory leaks daily?

To answer these questions I have create a module within JBossProfiler that could be used on testcases to assert the expected state of your memory. There is no Java API you could use to evaluate what classes you have in the memory or what objects you have in the memory. Most of the metadata is done through classLoader, but you can’t inquire about what’s on the memory.

JVMTI can give you lots of that information, but this is a C++ layer. I have then created a JVMTIInterface, a java interface working as a wrapper to JVMTI where you can inquiry about any inventory information on the JVM.

You have some nice functions like:

• forceGC
• getLoadedClasses
• Object getObjectsOf(Class)
• Map inventory = produceInventory
• compareInventories(Map,Map,ignorePoints…)
  

You can now execute your testcase, and perform assertions on anything about the memory. Like you could make sure that a class was unloaded (i.e. the classLoader was released), or check if the number of instances on the memory is steady and nothing unexpected is being created.

This is a good thing, since even with Garbage Collections in complex software there is always the possibility of a thread not receiving the right message and keeping objects referenced when they were supposed to be released.

Once you find a memory leak, keeping the memory leak test in your testsuite will raise an alarm if something start to leak in the future. As soon you check bad code, your test will start to fail what means FIXME as soon as possible.

Another good thing also is, you don’t need an expensive tool to use that new technique. The tool is free and open source :-).

Also this is a much better approach then running soak tests and waiting the JVM to survive. You could test a much better test scenario.

Example:

 public void testMessage() throws Exception

 {

  

  JVMTIInterface jvmti = new JVMTIInterface();

  Object obj = TestDomainObject.createTestInstance();

  Map snapshot1=null;

  Map snapshot2=null;

  for (int i=0;i<1000;i++)

  {

   if (i==100)

   {

    snapshot1=jvmti.produceInventory();


   }

   ByteArrayOutputStream byteOutputStream = new ByteArrayOutputStream();

   JBossObjectOutputStream jbout = new JBossObjectOutputStream(byteOutputStream);

   jbout.writeObject(obj);

   jbout.flush();

   

   ByteArrayInputStream byteInput = new ByteArrayInputStream(byteOutputStream.toByteArray()); 

   JBossObjectInputStream jbinput = new JBossObjectInputStream(byteInput);

   Object newObject = jbinput.readObject();

   assertEquals(newObject,obj);

  }

  snapshot2 = jvmti.produceInventory();


  

  assertTrue("Produced unexpected memory",


    jvmti.compareInventories(System.out, snapshot1, snapshot2, null, null, null));


 }

I’m going to show how to create such testcases on my presentation at JBossWorld this week. I hope I could see you there on the show.

If you have comments about this blog, you could use JBossProfiler forum.