Community
Participate
Working Groups
If you execute comparison over two big models and open the result on the compare editor: ComparisonResourceSnapshot snapshot = DiffFactory.eINSTANCE.createComparisonResourceSnapshot(); snapshot.setDiff(diffModel); snapshot.setMatch(matchModel); ModelCompareEditorInput editorInput = new ModelCompareEditorInput(snapshot); CompareUI.openCompareEditorOnPage(editorInput, page); One can determine, using tools like VisualVM, that diff and match models are kept in the heap and not reclaimed. If you execute sequential model comparisons and open in the editor, the JVM instance will eventually run out of memory.
Some of the possible culprits being strongly-referenced: - ModelCompareEditorInput (i.e, org.eclipse.ui.internal.Workbench.editorHistory) - ModelCompareInput (among others, by ModelCompareEditorInput) - ModelComparator (by ModelComparator.INSTANCES)
From the Laurent Goubet at the newsgroup: "If the ModelComparator is not the culprit, you could also try the EMFModelProvider or EMFResourceMapping. These two are part of recent development on the integration with logical models, and are still a work in progress. I know that we load the two/three distinct resource sets from there, and I still have a FIXME pending to try and find a way to unload those resources. However, I confess I still don't know "where" or "when" to unload these. This particular issue is a pending work and will be completed by 1.3, but that might be the candidate you're missing to determine where the leak(s?) come from"
Victor, I have isolated a number of leaks with UML models, though could not try and get rid of everyone. This is my current task and should be completed sometime next week. For the record, ModelComparator does leak all compared Resources, as does AdapterUtils.FACTORY (this is an historic one, I wonder whether the behavior of the UMLAdapterFactory changed since then or if we simply failed to discover this leak). Unfortunately that second one is really tricky to get rid of.
Victor, The second source of memory leaks I isolated (AdapterUtils) seem to have been the last. I no longer see strong references to EMF objects with these two changes, and my heap goes back to 50-60Mo when I force a garbage collection through Eclipse. Can you verify the fixes with the latest code from Git, or would you rather I build a new integration version?
Laurent, thanks for the effort. I'll give a check by the end of the week. I can fetch the code from GIT, its not necessary to kick a build. Good Work! Víctor
Hi Laurent, I've been checking the recent changes. It seems the ModelComparator strong references are gone. However, from what I've tested, leaks still persist. After 2 comparisons, the heap gets full, and once I close the editor, forcing GC doesn't seem to lower the heap. A heap dump reveals that the only ones referencing the the 2 DiffModelImpl and 2 MatchModelImpl existing instances are: - ComparisonResourceSetSnapshotImpl - ModelCompareInput If you guys are not experiencing this issue, I'll try to work on it when I get some time (we are in the last iteration of our current project). Cheers! Víctor
Victor, could you provide us with sample models n which you experience this? I used somehow big models to try this, and haven't seen my heap grow too much (at least, when closing the editor the heap space can be retrieved).
Laurent, I'm afraid our models contain client information so we are not allowed to share that. My heap grows to 768mb on an 32-bit JVM instance. However, the process is not just comparison, there is a lot of pre-processing of the models before comparing. I create a test-plugin that does all the pre-processing of our models and then compares and opens the compare editor. So as you see there is other proprietary processes going on, so I want to make sure there isn't anything wrong in our code. However, profiling pointed out to code related with the comparison editor. Given the situation, I can only offer you guys feedback and to fix this by myself.
*** Bug 364270 has been marked as a duplicate of this bug. ***
There are no more "strong" references that leak when the comparison editor is closed, at least not any that I could observe since we last looked at that bug, two years ago. EMF Compare 1.3 is pretty clean as far as memory leaks are concerned. Closing.
