Le 27/07/2013 18:22, K. Gadd a écrit :
> Of course, I don't know how difficult it actually is to fix this.
Difficulty is obviously one major concern. If this was easy to fix, I 
imagine it would have already been done; JS engine maintainers don't 
keep easy-to-fix leaks for fun.
Also, apparently, it was easy in SpiderMonkey to make a tool that does 
the analysis [1]. A comment by Jeff Walden [2] suggests that the leak 
may not be fixed in the short term, though. The reason is that the 
analysis to figure out which variable to keep track of is a bit costly 
and doing it upfront would slow down JS runtime performance. Performance 
is a finite blanket; pulling one way uncovers another part. It takes a 
massive amount of work to have a slightly wider blanket.

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=894669
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=894669#c10

Le 27/07/2013 18:22, K. Gadd a écrit :
> Of course, I don't know how difficult it actually is to fix this.

Difficulty is obviously one major concern. If this was easy to fix, I 
imagine it would have already been done; JS engine maintainers don't 
keep easy-to-fix leaks for fun.
Also, apparently, it was easy in SpiderMonkey to make a tool that does 
the analysis [1]. A comment by Jeff Walden [2] suggests that the leak 
may not be fixed in the short term, though. The reason is that the 
analysis to figure out which variable to keep track of is a bit costly 
and doing it upfront would slow down JS runtime performance. Performance 
is a finite blanket; pulling one way uncovers another part. It takes a 
massive amount of work to have a slightly wider blanket.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=894669
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=894669#c10