Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Does it provide any support for avoiding/detecting Javascript "memory leaks" which are easy to create with closures and anonymous functions?

That's what interests me the most.

The stuff they have here for annotating types (love the type expressions), equivalent of #define are major conveniences to ease development. And long overdue. So thanks, Google.



Thank you psranga for being the only one in here to make a technical comment.

Leak profiling in JS is a pain. I wasn't really expecting Google to provide an answer here because all their apps contribute to wasted heap space too.

Google's answer (as far as I can tell) is just to push it back to the browser. In their case, use Chrome, which uses a separate process for each page.

Chasing JS leaks has to be one of the most frustrating exercises ever. I ended up using a windows tool for analyzing jscript.dll and cross-referencing this with a custom spidermonkey build (with lots of print statements in the source).

Anything less than insight to this problem I'm going to take with a grain of salt.


  > Does it provide any support for avoiding/detecting
  > Javascript "memory leaks" which are easy to create with
  > closures and anonymous functions?
I don't understand this. Do closures leak because of buggy javascript implementations or is there something about them that fundamentally prevents the interpreter from being able to tell when to garbage collect them?



Firefox 3 no longer has this problem: https://developer.mozilla.org/en/interfacing_with_the_xpcom_...

Reference counting GC is the problem, not closures.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: