|
Re: Memory Leak issue in GEF Module [message #1819253 is a reply to message #1818758] |
Fri, 10 January 2020 14:17   |
|
Hi Giri,
it would help a lot if you could trace down the memory leak, i.e. find specific references not cleared.
I do know that some places in the codebase might be leaking, e.g. the adaptable scope mechanism maintains a static map that cannot be cleared.
Usually, however, memory leaks have got to do with references to model elements. Those might be coming from JavaFX event handlers not being removed.
You should be able to track it down using a memory analyzer/profiler, e.g. YourKit or VisualVM, looking for your model elements (large memory footprint).
Best regards,
Matthias
|
|
|
|
Re: Memory Leak issue in GEF Module [message #1822390 is a reply to message #1821944] |
Thu, 05 March 2020 12:59   |
|
Hi Girijanandan,
the keys in this map are weakened. Therefore, entries should be removed when they get garbage collected.
Since there is still a visual registered in visual-part-map, the viewer does not seem to be properly disposed. Disposal sets the adaptable-property of all adapters (that are adaptable-bound) to null. As soon as a part (adaptable-bound) loses its viewer (adaptable), it will unregister from its old viewer.
Therefore, I believe there should be some underlying issue preventing disposal, or an error w.r.t. unregistration, or something else.
I know it is hard, but I believe you need to dig deeper.
Some things to try:
1) When closing the visualisation, ensure that contents are cleared and viewer is disposed. Investigate state of visual-part-map, content-part-map, and viewer models (e.g. selection model). You should hopefully know more after doing this.
2) In a memory snapshot, try to follow reference chains to find root causes preventing garbage collection. Candidates for this are registered event handlers referencing model data (or a chain leading to model data).
If you have more insights to share, please do!
Best regards,
Matthias
|
|
|
|
Powered by
FUDForum. Page generated in 0.02338 seconds