[m2e-dev] memory leak: MavenClasspathContainer instances grow in JavaMod

[Martin Koci <martin.kocicak.koci@xxxxxxxxx>]

Hi,

I found a memory leak (probably). Tested environment: Indigo SR2, web
tools 3.3.2, m2e 1.1 M6

Use case: repeatly perform "Update project". Instances of
org.eclipse.m2e.jdt.internal.MavenClasspathContainer grow constantly.

Analysis of heap dumps performed with Memory Analyzer shows, that
immediate dominator for MavenClasspathContainer are
org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer
instances and its 'resolvedContainers' attribute (from JavaModelListener
parent).
org.eclipse.jem.internal.adapters.jdom.JavaReflectionSynchronizer is a
class from org.eclipse.jem.workbench bundle ( comes with WTP).

This listener is installed for project with
"org.eclipse.jem.workbench.JavaEMFNature" nature (does add this nature
m2e or m2e-wtp automatically ?)

I don't  know exactly where the problem is, only two ideas:

1)
code from
org.eclipse.jem.workbench.utility.JavaModelListener.processDelta(IJavaElementDelta):

if (((flags & IJavaElementDelta.F_RESOLVED_CLASSPATH_CHANGED) != 0) && !
resolvedContainers.isEmpty()){
			resolvedContainers.clear();			
		}

there is a flag F_RESOLVED_CLASSPATH_CHANGED - maybe m2e should set this
flag?

2) JavaModelListener uses container as key into HashMap
 resolvedContainers.put(container, containerEntries);

but MavenClasspathContainer class has equals/hashCode from
java.util.Object - maybe implement equals/hashCode
MavenClasspathContainer with some logical equality?


I'll create a issue for this in bugzilla and attach screenshot from
Memory Analyzer.


Regards,

Martin