Instances referenced by 'bound_this' only are not garbage collected

后端 未结 3 1341
孤独总比滥情好
孤独总比滥情好 2021-02-05 02:14

I have a question regarding garbage-collection in google chrome (Version 20.0.1132.47, Ubuntu 11.04 64bit).

While comparing heap-dumps and checking for memory-leaks, I d

相关标签:
3条回答
  • 2021-02-05 02:17

    Your suspicions that this is not an actual memory leak but weirdness with chrome is correct.

    I recently ran across the same problem. IE11 will not show this.func = _.bind(this.func, this) as a memory leak while chrome will, even after you press the collect garbage button 100 times.

    It will show it even after you run chrome with the jsflag nonsense and expose the underlying garbage collector and call gc 100 times.

    A easy way to prove that it is in fact not a leak in chrome is to make a minor issue a major issue with the browser and force the engine to take action.

    On the instance that has the bound function assigned to it assign a new property like this:

    target.WhyAmILeaking = new Array(200000000).join("YOURNOT");

    Do the three snapshot technique with chrome and you'll see that string present in the heap clocking in at around 214mb. Do whatever constructive action (the second snapshot) again and you'll see the heap go to 423mb or stay at 214mb. If it stays you're done as you proved the original 214mb has been collected. If it doesn't stay do your destructive action (third snapshot) and it'll go back to 214mb also proving the original got collected.

    If it just stays at 423mb you sir or madam have a leak.

    Oh and another group of poor souls that ran across the exact same situation: https://github.com/jashkenas/backbone/issues/2269#issuecomment-13610969

    TL;DR; use IE 11 for detecting leaks.

    0 讨论(0)
  • 2021-02-05 02:26

    I have referred this in EcmaScript, this term "bound this" with class,

    Class methods have “bound this”, where this in the method body is always bound to the class instance from which the method was extracted, regardless of what this parameter is actually passed in to the method (the this parameter to the method is ignored).

    Now here in your example there is no sample script given so can not be specific to question,

    I have to say if this is not leak..

    then with what ever object, class the script is bounded, it will not call garbage until the class/object exist as this function is bounded with the same object.. it will garbage collected only after its parent's(the object/class with which it is bounded) scope ends.

    Now if circular reference when the task will finish it will come to end,>> this works like concept of Recursion(mind it concept, not same as).. so the end will start from the last call.. in reverse.. the inner most call(latest call) will be released first.. and so on

    The code must be buggy as they must not bind and define function and reuse each time.. but if they are binding then also it should work fine and should not leak until the footprint goes out of the browser limit of memory pool.

    I hope this will explain..

    0 讨论(0)
  • 2021-02-05 02:27

    Are you triggering a "forced GC" using the developer tools? If that is the case and the objects then persist then the research above is of value.

    If you are not triggering a GC via the developer tools, then do remember that the way the GC engine works is quite complicated and it has the concept of generational collection (using two generations).

    http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/#toc-v8-gc

    It could simply be that you have not reached the required threshold to trigger a young generation GC, or that the objects have been tenured to the old Generation but that a old generation GC was never triggered.

    Unfortunately the developer tools don't seem to show which generation was GC'd.

    0 讨论(0)
提交回复
热议问题