Memory leak issue and tween _next

[autoric]

Hi Greensock!

 

I'm experiencing a memory leak in my application of DOM nodes and timelines. When I inspect the detached dom the shortest retaining path appears to be via a series of _next properties on other tweens and timelines.

 

 

Ultimately, I have a reference to some timeline or tween that I am maintaining correctly - it should still be available and in memory. And then, via a chain of _next / _prev properties, I seem to have references to timelines or tweens that I am done with but are still hanging around. And these are maintaining references to their target dom nodes. 

 

It's possible I am misreading the profiler, or there is something going on. But I would appreciate any advice on what I should look at or do differently to manage my tweens correctly.

 

Thanks!

[GreenSock]

Any chance you could create a reduced test case in codepen (or something) and post it here? Are you saying those references stay intact even after 10-20 seconds? There's a gc routine that runs every 120 ticks, clearing things for the browser's gc (which is somewhat unpredictable). 

[autoric]

I will try to reproduce with a codepen. There is interaction between angular and greensock that could be complicating the issue. 

 

In short I am creating a timeline when I link a directive, and .kill()'ing that timeline when the directive scope is destroyed (and I can confirm that this is happening). However I end up seeing references to the .kill'ed timeline via the next chain, which I understand to mean that it is still referenced on the global root timeline. 

 

Even waiting a minute or more, I continue to see the timelines referenced via the _next chain.

[autoric]

I'm actually not sure how to effectively create a codepen here. Running the profiler on the basic codepen does not show me a timeline instance.

[GreenSock]

Does this help?: http://forums.greensock.com/topic/9002-read-this-first-how-to-create-a-codepen-demo/

 

I'm having a tough time imagining how references would be maintained like that unless you've got something referenced in your own stuff. I'm not saying it's not a bug in GSAP - I'm just struggling to know how to track it down if I can't even see it reproduced somehow. We've had some gc experts analyze GSAP in the past and give us "thumbs up", but that doesn't mean some glitch/bug hasn't crept in since then. I'm eager to squash any bugs, that's for sure - I just need your help reproducing it in a reduced test case. 

[autoric]

So, it looks like timelines, including the root timeline, maintain a linked list of their child tweens and timelines. 

 

Referencing the code here: https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/TweenLite.js#L758

 

When a tween is removed via completion or .kill, it takes its _next and _prev references and points them at one another. It does not then null its own _next and _prev references. This is technically valid, since it should be dereferenced and eligible for gc. However, if I write some bad code that keeps that tween alive in closure, I now have a reference path to its old next and prev tweens - which are probably also dead, and whose next / prev tweens point to other dead tweens. Etc, etc, etc.

 

Conclusion: The memory leak is caused by my bad code, but is made worse because removed tweens do not null their _next and _prev pointers, creating a large network of references that get kept alive by my leak. Unless there is a specific reason to keep the _next & _prev pointers of removed tweens alive it probably makes sense to null them in order to mitigate the impact of leaks.

[GreenSock]

Thanks for the detailed feedback and recommended solution. It was originally a performance optimization (we shouldn't have to specifically set _next and _prev to null), but I see how it could make someone's faulty code worse, and it's not like setting those properties to null imposes a huge performance bottleneck or anything, so I plan to implement that change in the next drop. Thanks again for the explanation.