Node/Memory leaks after garbage collection
Node/Memory leaks after garbage collection
DBohling
Posts: 5Questions: 1Answers: 0
Hi,
I was profiling my web app for memory leaks, and noticed that the number of nodes and heap space continuously grows. I came across this discussion and it seems to be consistent with what I'm seeing.
I am calling the destroy() API method when leaving the page; I see that the number of listeners drops as expected, but it is holding onto nodes and thus using more heap space as time goes on. You can see the memory profile timeline with these screenshots: start and end
I was just curious if this has been addressed in the most recent releases of the library. FYI I am using DataTables 1.10.9
Cheers
This question has an accepted answers - jump to answer
This discussion has been closed.
Answers
As far as I am aware there are no leaks in the current release of DataTables. However, if you think you have found one please link to a test case showing the issue.
Allan
Well the screenshots I linked to are my test case. All I did was go to the page with the datatable and leave the page and let it idle. You can see the 7.6k nodes jumped to 10.8k nodes and never went back below. I can redo the same test from the start of the application, but I suspect the results would be the same.
This isn't an accusation - I'm just asking, because I came across that thread that matched what I'm seeing and never saw any comment on a resolution.
Yes I can see that there might be an issue, but in order to be able to debug it I would need a test case showing the problem. I don't know what configuration you are using on your page, any third party libraries, any first party extensions, etc. All of them could have a bearing on leaks.
Allan
Yes that's certainly fair. My app is using a project called angular-datatables that provides an Angular wrapper API. I don't doubt that it might be compounding the issue.
However, per your suggestion I've made a JSFiddle isolating the library. My test case was creating the table with a hidden column, destroying it, creating it again, and destroying it a second time.
You can see in the timeline at what points this process is taking place. (Note: The yellow line is event listeners, the blue line is heap memory, and the green line is the number of nodes) I did another timeline recording letting it idle for a long period of time after the last destruction, but the trail end of the graph was identical; the node count does not go down.
These are images of the graph only: start and end
Here are some results for the process after several more iterations.
Thanks for the link. This link with without all the JSFiddle embedding stuff which makes it easier to test.
Using Chrome's heap allocation timeline and clicking between the build and delete buttons I can see that there doesn't appear to be any leaks. On each iteration Chrome might cache a little bit of code to optimise or another string, but there doesn't appear to be a DOM leak (events or elements).
One thing to keep in mind about the V8/Chrome heap management is that the garbage collector in V8 is "lazy" - i.e. it can grow for a long time before it actually gets fully cleaned up.
Further to that, Chrome won't always clean up as much as possible all the time it can keep old elements kicking around in memory for a while before it tidies them which can be quite frustrating when debugging. For example in your "several more iterations" if you have kept going I would expect it to clean up lots of nodes all at once.
The key is the retention map - if there is a reference to the node then it can be cleaned up (regardless of when that happens).
The Heap Allocation timeline is the way I've found it easiest to understand and find leaks with the Chrome dev tools and there doesn't appear to be one here.
Allan
Ah thank you for updating the link. I didn't know that was possible to get rid of all of the embedding stuff. That makes sense what you are saying, and you clearly know more about using the Chrome Timeline and how it does it's garbage collection than I do.
There are still some questions I have though. How long does it usually take for the GC to clean up those nodes left in the retention map? Here I waited a good 40 seconds, and I thought that would be plenty of time. My Heap Space grew from 3.3MB - 5.5MB which might not sound like much, but this is a very small table compared to a common use case. I wouldn't have this much concern, but my application is using the library in a single page application where they won't be closing it often or navigating away.
You can see at the top of the timeline I linked that the allocated Heap Space never goes down after the idling period. Is the Heap Allocation Timeline you're referring to something different?
P.S. - I think this library is amazing and I've been using it fondly for years now. I'm sure that you have put a lot of time and thought into the cleanup side of things. I was just exploring options for where a memory leak might be coming from.
As for the memory growth depicted in the graph from my last comment - if you think that is negligible I will accept that and try to work around any cases specific to my application.
Cheers!
Completely variable. My understanding is that since it is "lazy" it will only do it when it actually needs to. So you would need to keep running the function - eventually you should see a saw tooth like like with it gradually going up and then dropping back down all of a sudden.
Sort of - click on the "Profile" tab and select the "Record Heap Allocations". Then toggle the state a few times (possibyl lots - Chrome keeps adding optimisations as it needs) and click stop. You should see a number of blue and grey bars.
The bars are memory that was allocated. The grey is memory that was / can be released. The blue is memory that cannot be released. If you click in the time chart you can zoom to each bar and see what has been retained. If there are elements in an old one, then that's bad new since they haven't been released.
Personally I find debugging memory leaks in Chrome really quite challenging because of this behaviour. Some kind of flag that told it to do aggressive memory release would be really welcome as I think some of the charts can be a bit misleading when looking for leaks. I've been on the Chrome dev list to ask about this before as I was going a bit crossed looking at it and trying to figure out what was going on. The retained items are the key and the heap allocation profile is the best way I've found of finding a leak.
Allan
edit
Thanks :-). There has been a fair amount of work on it, but bugs still happen!