Static `super` may cause a unwanted "memory leak".

Michał Wadas michalwadas at gmail.com
Sat Aug 6 10:32:54 UTC 2016


Specification doesn't guarantee any optimization, not even garbage
collection, so conforming implementation can allocate objects until OOM.

On Sat, Aug 6, 2016 at 5:57 AM, /#!/JoePea <joe at trusktr.io> wrote:

> Ah, interesting to know. Is such an optimization guaranteed?
>
> */#!/*JoePea
>
> On Tue, Aug 2, 2016 at 1:59 PM, Jason Orendorff <jason.orendorff at gmail.com
> > wrote:
>
>> On Tue, Aug 2, 2016 at 3:09 PM, Bergi <a.d.bergi at web.de> wrote:
>>
>>> Why would `tmp` be stored as the [[HomeObject]] when the function
>>> doesn't use `super`? In that case a [[HomeObject]] is not needed at all.
>>>
>>
>> To clarify this: of course the JS engine knows whether the code uses
>> `super` or not and can decide to retain the [[HomeObject]] only when
>> there's some danger of its actually being needed. But do implementations
>> actually do this optimization in practice?
>>
>> SpiderMonkey has a findPath() primitive that searches the GC heap for
>> paths from one object to another, handy for answering questions like this
>> one:
>>
>>     js> function SomeFactory(name) {
>>       let tmp = {
>>         [name]() { /* this doesn't use `super` */ }
>>       }
>>       return findPath(tmp[name], tmp);
>>     }
>>     js> SomeFactory("foo") === undefined
>>     true
>>
>> That is, there is no GC-path from the method back to the object;
>> apparently [[HomeObject]] is not being retained. What if we change the
>> method to use `super`?
>>
>>     js> function SomeFactory2(name) {
>>       let tmp = {
>>         [name]() { return super[name](); }
>>       };
>>       return findPath(tmp[name], tmp);
>>     }
>>     js> typeof SomeFactory2("foo")
>>     "object"
>>     js> SomeFactory2("foo").length
>>     1
>>
>> Now there is a direct GC-reference from the method to its home object, as
>> expected.
>>
>> -j
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160806/d3f1ab3e/attachment-0001.html>


More information about the es-discuss mailing list