| Summary: | [Model Browser] Memory increases when closing the model browser | ||
|---|---|---|---|
| Product: | [Modeling] MoDisco | Reporter: | Nicolas Guyomar <nicolas.guyomar> |
| Component: | Infrastructure | Assignee: | Nicolas Bros <nicolas.bros> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | fabien.giquel, gdupe, hugo.bruneliere, modisco.web-inbox, nicolas.bros |
| Version: | 0.8.0 | Flags: | nicolas.bros:
helios+
|
| Target Milestone: | 0.8.2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Nicolas Guyomar
When the browser is closed, it unloads the edited resources. This causes a temporary spike in memory usage. But this memory should be freed by the GC eventually, or immediately if you click on the garbage bin icon on the heap status bar in Eclipse. To easily determine whether the browser is leaking memory, you can open and close models repetitively, and trigger the GC manually each time (clicking on the bin icon) . If memory usage increases each time, then you have found a leak. I don't see the memory usage increasing when I follow this method. I have doubt about the utility of calling the unload methods, since the ResourceSet instance is not reused after closing the MoDisco browser... We see that calling 'unload' has some disadvantages : - memory and may be time cost - some misc bugs (see bug 318391) In comparison the "sample reflective ecore model editor" does not call "unload" when closing. Does someone see a reason to maintain such "unload" calls ? You are right Fabien, calling unload seems unnecessary. I have removed the call to "unload" when the browser is closed (revision 2964). I checked, and it doesn't seem to be leaking memory when repeatedly opening/closing large models. Hi, Should we apply this patch on the branch 0.8 ? Grégoire Too late for SR1. Maybe for SR2? Hi, We have to report the fix of this bug in the branch 0.8, because the fix can avoid memory problems. Regards, Grégoire I applied the modification to branch 0_8 (for SR2) in revision 3233. Bug fixed. |