Memory leak when creating and deleting views in SAPUI5/OpenUI5

Question

I’am using OpenUI5/SAPUI5 to write a test application and even after a lot of testing, optimizing and researching I still seem to have a memory leak.

I have several views with a controller attached to it and navigate between them using the SplitApp control of SAPUI5. Whenever I navigate back I destroy the view like this:

// Get current page
var sCurrentDetailPage = this.oSpiltApp.getCurrentDetailPage().getId();
// Go back
this.oSpiltApp.backDetail();
this.oSpiltApp.removeDetailPage(sCurrentDetailPage);
// Destroy current page
sap.ui.getCore().byId(sCurrentDetailPage).destroy(true);

Since I couldn’t get rid of all the content a view maintains I manually added destroy calls to their elements in the onExit function of the controller (onExit is called when destroying a view). Even though the destroy call to the view should destroy its children as well, this seems to get rid of some more elements, but still not enough. I’m only using events and click handlers provided by SAPUI5 that should be detached when calling destroy and if a view is subscribed to an event I unsubscribe in onExit.

The problem:

If I create and navigate to a new view and then go back (destroying the view) only about half the memory allocated seems to be freed again. So I would for example open a view, go back and take a Heap Snapshot in Chrome which shows me 20MB. Then I open and close the same view 5 times and end up with 20.5 MB. So for this specific view 100KB are not deleted when destroying it. If the app is in use the whole day (which it is intended to be) this could cause problems on older mobile devices. Does anyone have experience with this problem? Thank you very much.

Edit

I recorded the memory use with the Chrome Timeline. I repeatedly created two views and destroyed them again. For the JS Heap I got the following result:

So it seems to grow massively over time.

For the nodes and listeners I got this result, which seems to be ok to me:

Would you say this is a memory leak or am I overreacting? Is this test even reliable? Thank you very much.

I noticed the following issue: stackoverflow.com/questions/33257288/… so could be that you have a similar problem? — user3783327
@user3783327 Thanks for your input. In my case a view seems to still occupy about 150KB after it was destroyed, even if no data was loaded. So it's not just the data that is my problem. But I'll check what happens with my data when I try to delete it. — Ben

Greg Burghardt Greg Burghardt · Accepted Answer · 2015-10-09T11:21:58

It is normal for browsers to hold on to memory. JavaScript is a garbage collected language, so nullifying object references or utilizing the delete keyboard does not trigger the garbage collector to free that memory.

Memory garbage collection in modern browsers usually happens in two phases:

The object graph is inspected. Any objects not referenced by anything from the "global context," e.g. the window object in the browser, are marked as "stale".
The next time the garbage collector is run, all previously "stale" objects have their memory freed and returned for available use by the browser -- note that this memory is not "freed" from the standpoint of the operating system. The browser holds on to those memory addresses in case it needs them again.
After the "stale" objects are freed, then the browser goes back to step #1 again to mark the next batch of objects as "stale".

Furthermore, most browsers only allow the garbage collector to run for a set number of milliseconds, because during this time the UI in the browser is technically non responsive so the object graph under inspection doesn't mutate mid-run.

The real test for memory leaks is to utilize the built-in browser tools for memory profiling. I know Chrome and Firefox have this feature. Secondly, over time -- and I mean over 10 to 15 minutes -- you should see a saw tooth pattern to the memory allocated to the browser where the short term trend is up-and-down, but the overall trend is flat.

      .      .      .      .      .
    . |    . |    . |    . |    . |
  .   |  .   |  .   |  .   |  .   |
.     |.     |.     |.     |.     |

If you see a saw tooth pattern over time where the overall trend is upwards, then that could indicate a memory leak.

                                 .
                        .      . |
               .      . |    .   |
      .      . |    .   |  .     |
    . |    .   |  .     |.       
  .   |  .     |.       
.     |.

Really the true test is using the built in performance monitoring tools that ship with the browser.

Memory leak when creating and deleting views in SAPUI5/OpenUI5

1 Answers