Community
Participate
Working Groups
In IBM product on RAD 1. Create a web project with faces 2. Create web page say about 8 or 10 pages 3. close all editors. 4. delete the web project 5. If you look at the objects in the heap, there are quite a few org.eclipse.jst.j2ee.componentcore.J2EEModuleVirtualComponent +8 +0 % +256 +0 % 9 0 % 288 0 % org.eclipse.jst.common.jdt.internal.integration.ui.WTPUIWorkingCopyManager +8 +0 % +320 +0 % 8 0 % 320 0 % org.eclipse.jst.common.jdt.internal.integration.JavaArtifactEditModel +8 +0 % +896 +0 % 8 0 % 896 0 % org.eclipse.wst.common.internal.emfworkbench.validateedit.ResourceStateValidatorImpl +8 +0 % +192 +0 % 8 0 % 192 0 % org.eclipse.wst.common.internal.emfworkbench.integration.EditModel$ResourceAdapter +8 +0 % +128 +0 % 8 0 % 128 0 % org.eclipse.wst.common.internal.emfworkbench.edit.ClientAccessRegistry +8 +0 % +128 +0 % 8 0 % 128 0 % org.eclipse.wst.common.internal.emf.resource.Translator[] +8 +0 % +384 +0 % 8 0 % 384 0 % org.eclipse.wst.common.componentcore.internal.resources.VirtualFolder +8 +0 % +256 +0 % 9 0 % 288 0 % org.eclipse.wst.common.componentcore.internal.impl.ComponentResourceImpl +8 +0 % +448 +0 % 8 0 % 448 0 % The common pattern of the leak was JavaArtifactEditModel being in memory, FacetProject also was in memorry, see below org.eclipse.jst.common.jdt.internal.integration.JavaArtifactEditModel (#00a43ba4) [29] of java.lang.Object[38] (#00f0cc41) elementData of java.util.ArrayList (#00e14529) listeners of org.eclipse.wst.common.project.facet.core.internal.FacetedProject (#013e7b3e) value of java.util.HashMap$Entry (#00b6e32d) [7] of java.util.HashMap$Entry[16] (#0020b894) table of java.util.HashMap (#00527fae) projects of org.eclipse.wst.common.project.facet.core.internal.ProjectFacetsManagerImpl (#01c03a2e) impl of org.eclipse.wst.common.project.facet.core.FacetedProjectFramework (#0104a74c)
*** Bug 154188 has been marked as a duplicate of this bug. ***
Created attachment 48325 [details] Perf patches
I found a couple problems with our disposal methods on EditModel and ResourceSetWorkbenchEditSynchronizer The Editmodel was calling the privateMethod "doDispose()" directly from the releaseAccess method when the reference had gone to 0, thus ignoring any subclass overrides of "dispose()" I changed to call dispose() directly - which also handles the "startdispose()" The Synchronizer class was holding on to an instance of a resourceDelta, even after disposal.... these can be quite large - also nulled out the "extenders" list Submitting for review....
approve
Won't the addition of the @Override annotation cause a build brekage?
Hmm not sure... this was just added via the eclipse source stub wizard... I can remove it.
Reject The problem I have is with the dispose() method on EditModel. In the superclass the startDispose() method is setting the isDispossing flag. In doDispose() the PRE_DISPOSE notification is sent and the isDispossing flag is set back to false. The problem I have is that subclasses are overriding the dispose method. This is bad because the PRE_DISPOSE event is not fired consistently and the isDispossing flag is not set correctly for the subclasses. I spoke with Jason and we have a proposed change for this problem. He will attach another patch.
After discussing with Jason and Dan we have decided to restrict the use of dispose() in the subclasses, and exposed doDispose() because of timing issues with the disposing flags etc... new patch attached
Created attachment 48370 [details] New Patch
Though it;s internal, are these extenders of this class that need to react to this change or is this just been done in the base and will not impact any extenders?
Approve
Dropped to build
OK
performance bugs should use performance keyword (no need to use [performance] in summary).
