Memory Leaks need to be eliminated to Improve NetBeans Fitness

Memory leaks seem to be one area not well covered by automated test yet. That shall change, especially as it does not require any major changes into the infrastructure. Our current infrastructure assertGC with cooperation of JUnit or Jemmy/Jelly tests is good enough to allow us to write reliable tests looking memory leaks up, providing enough info to easily fix them and preventing their re-appearance in the system. issue 121855 or proposal for reuse of timers/counters infrastructure demonstrates the initial attempts in this area. Based on that work, this page provides a how-to tutorial of using our Memory Leak Testing Infrastructure.

Who should do what?

It is unlikely to expect that other teams are going to write memory leak tests and that they will continuously look for memory leaks in their code. We need the Performance team to write the tests and moreover write them in a way that can discover errors in foreign code. This requires combination of good imagination and of integration testing, however issue issue 121855 shows that this is possible in principle.

The Memory Leak Testing Infrastructure was created and is currently maintained by Jaroslav Tulach.

The probes into production code shall be insert written by engineers that create the tests and either integrated directly, or via a patch submitted into issuezilla. The second approach needs a bit of presure on the module owner, so the patch is integrated in timely manner.

The set of tests, verifying that basic create, open, edit, compile, run, close operations on various project types is written by Performance QE team.

How to write memory leak test?

• Well, basically write any regular test that verifies some functionality.
• Make sure there is a probe inside of the tested code that reports instances that can cause memory leaks

File [changed]: ProjectManager.java
Url: http://projects.netbeans.org/source/browse/projects/projectapi/src/org/netbeans/api/project/ProjectManager.java?r1=1.38&r2=1.39
Delta lines:  +9 -1
-------------------
--- ProjectManager.java 26 Sep 2007 21:04:26 -0000      1.38
+++ ProjectManager.java 14 Dec 2007 16:11:26 -0000      1.39
@@ -85,6 +87,8 @@
     // XXX change listeners?
     
     private static final Logger LOG = Logger.getLogger(ProjectManager.class.getName());
+    /** logger for timers/counters */
+    private static final Logger TIMERS = Logger.getLogger("TIMER.projects"); // NOI18N
     
     private static final Lookup.Result<ProjectFactory> factories =
         Lookup.getDefault().lookupResult(ProjectFactory.class);
@@ -347,7 +351,11 @@
         for (ProjectFactory factory : factories.allInstances()) {
             Project p = factory.loadProject(dir, state);
             if (p != null) {
+                if (TIMERS.isLoggable(Level.FINE)) {
+                    LogRecord rec = new LogRecord(Level.FINE, "Project"); // NOI18N
+                    rec.setParameters(new Object[] { p });
+                    TIMERS.log(rec);
+                }
                 proj2Factory.put(p, factory);
                 state.attach(p);
                 return p;

• Before your test starts, initialize the memory leak tracking infrastructure

 org.netbeans.junit.Log.enableInstances(Logger.getLogger("TIMER"), Level.FINEST); 

• When your test is about to finish, assert that all collected instances can be GCed

 org.netbeans.junit.Log.assertInstances("Everything is OK"); 

That is all. Enjoy writing your memory leaks tests!

What to do when you find a memory leak?

Report an error just like 124040 or 124038 or 124042. Add PERFORMANCE and TEST keywords to the issue and into status whiteboard added perfleak word, that way we will be able to list all leaks fixed in 6.1 time frame.