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

[/#!/JoePea]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160805/42639209/attachment-0001.html>