Bugzilla – Full Text Bug Listing
| Summary: | STEM heap allocation keeps increasing over time | ||
|---|---|---|---|
| Product: | [Technology] STEM | Reporter: | Stefan Edlund <sedlund> |
| Component: | Core | Assignee: | Stefan Edlund <sedlund> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | mattadav |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Stefan Edlund
I've tracked down the main memory leak to the org.eclipse.emf.common.util.URI$URICache that can actually grow REALLY large since: 1. Every URI that is created ends up in this cache 2. We create lots of unnecessary URI's in STEM that are just thrown away. 3. The URICache is using weak reference values to allow for garbage collection, but the keys in the cache are not cleaned up until a limit is reached (1000 initially) and the limit keeps growing larger and larger if you create lots of URIs. One problem is that in STEM we create URI's in the constructor of IndentifiableImp. The constructor is called when EMF is deserializing any identifiable (Nodes, Edges, Graphs...) and the value we set in the constructor is overwritten but still ends up in the URI cache. The fix is to not call setURI in the constructors of STEM identifiables, but higher up in the call stack only when necessary. This change will affect many places in STEM so we need to carefully test the code after fixing. Stefan is working on the fix. Should be in by August 1. *** Bug 311295 has been marked as a duplicate of this bug. *** Adding myself to CC A fix has been checked in that does the following: 1. Gets rid of the automatic generation of a URI for identifiables, nodes and edges in the constructor of those classes. Instead a URI is generated and set by the class that creates new instances of nodes, edges and identifiables. This way we avoid generating and tossing away lots of uncessecary URIs when deserializing EMF objects. 2. A big memory hog was the project explorer. It calls Utility.getIdentifiable(...) and inside that method a new resource set was created each time, so we did not take advantage of the caching provided by that class. Now there's a single resource set that's reused to support caching of resources. One complication is that resources in the resource set needs to be marked modified whenever a "child" resource is modified. For instance, a scenario needs to be refreshed if a containing model is updated (or a sub-model of a model etc.). In the IdentifiableContentProvider and the visit method, we get a callback whenever a resource is modified in the editors. We now check and mark other resources that needs to be reloaded due to the update. 3. The GraphItemProvider automatically sorted alphabetically its children in the getChildren() method. This can be very expensive for large graphs having lots of nodes, edges and labels. I took out the sorting and it greatly improved the performance when editing large graphs. If we feel that we need to support sorting of children, we can revisit this and figure out how to be smarter about the sorting. I will mark this fixed for now, but might re-open it (or create a new one) if we find that the solution is not enough or that it's causing other unexpected behavior. Complete |