Community
Participate
Working Groups
The JavaModelListener uses the resolvedContainers hash map to cache some classpath container entries which causes a memory leak when using m2e and creating an EAR project. M2e updates a classpath using the following code: (http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/BuildPathManager.java): IClasspathEntry[] classpath = getClasspath(project, monitor); IClasspathContainer container = new MavenClasspathContainer(path, classpath); when updating the project's classpath. This code doesn't create ElementChangedEvent of the IJavaElementDelta.F_RESOLVED_CLASSPATH_CHANGED type because neither the container's path nor the container's attributes are changed. That's why the resolvedContainers hash map isn't cleared (JavaModelListener.java, lines 107-109). However, this map doesn't contain the project's classpath container anymore and a new container is added to the map (JavaModeListener.java, lines 361-365). The map will leak the old Maven classpath container and all its entries. For instance, rebuilding the project created using the org.jboss.spec.archetypes:jboss-javaee6-webapp-ear-archetype maven archetype will leak several thousands IClasspathEntry/IClasspathAttribute objects. I think, the issue can be solved in two ways: 1. using the container's path instead of container as a key for the resolvedContainers hash map In my opinion, this is not a good solution because some container can return a different result when ever its getClasspathEntries() method is called. 2. removing the resolvedContainers hash map completely and letting classpath containers to cache their entries. Attached is a patch that uses case #2.
Created attachment 225855 [details] A patch
Created attachment 239758 [details] A patch The problem is still reproducible in Luna. I have rebased the patch.
A memory leak is a pretty critical issue that can eventually lead to performance issues the longer a user keeps his workspace open, leading to the impression that the product is slow and bloated. Bumping severity.
Hi, Could you attach a project or projects to recreate the problem? and the steps to recreate the issue? For example, import projects, then add a dependency to pom of project x.
Hi, The reason I asked for the steps to recreate the problem is that I want to see if another type of event is triggered when the Maven classpath container is updated, and maybe we can check in JavaModelListener for that event besides IJavaElementDelta.F_RESOLVED_CLASSPATH_CHANGED The attached patch basically removes the fix for bug 236434, so in my opinion, applying this patch would fix a memory leak but bring back another performance issue.
During the WTP status meeting was decided to reduce the severity. Reducing to Major
(In reply to Roberto Sanchez Herrera from comment #4) > Hi, > Could you attach a project or projects to recreate the problem? and the > steps to recreate the issue? For example, import projects, then add a > dependency to pom of project x. You can create a project using the org.jboss.spec.archetypes:jboss-javaee6-webapp-ear-archetype maven archetype. M2 is required in order to reproduce the issue. The fix for bug 236434 will help if there are classpath containers that don't cache the classpath entries. If a container doesn't cache its entries, that will cause bad performance in other parts of Eclipse. Also, you can't be sure that classpath containers will always return the same entries so that this fix can disrupt a functionality. That's why I haven't used the solution #1 from https://bugs.eclipse.org/bugs/show_bug.cgi?id=398568#c0.
