On Oct 25, 2012, at 23:13, "Andrew Paprocki" <[email protected]> wrote:
> On Thu, Oct 25, 2012 at 10:14 PM, Shawn Steele > <[email protected]> wrote: >>> On the contrary, "TypeError: Cannot read property 'prop' of undefined", >>> with a stack trace, is WAY easier to track down than "The RSS on my server >>> gradually rises, until the operating system kills it, which happens about >>> every 4 hours." >> >> I'm not so sure. Now you know where you're using it that you didn't think >> you were, but you've now got something freeing it that's not supposed to. >> So you might have to check each of those "free"s to see where they weren't >> supposed to free, possibly without much context at the other end. You've >> traded one problem for a different one. > > I can offer that we do this pretty commonly with certain native > objects wrapped into JS and that it is useful, albeit trading > problems, as you say. My personal observation is that it is much > easier for a large body of JS programmers to grasp this > "use-after-free" class of bugs than tracking down GC related issues > such as a closure capturing a scope to which someone unknowingly added > a variable keeping a whole tree of things alive. > > I would love it if tools could to a better job at illustrating why > objects are kept alive, though. There is no desire to standardize JS > bytecode or anything of that nature, but perhaps there is room to > standardize some kind of serialized GC heap view akin to a 'core' file > for debugging purposes so that tool writers have an easier job? There are already some pretty good debugging tools for inspecting the JS heap, both in Web Inspector and (for IE/Windows 8 users) in Visual Studio 2012 Update 1. Standardizing them seems not that useful; they're already working well. The new thing this proposal brings to the table is the ability to mark, from within your code, exactly what object you're worried about the leakiness of. You also get very understandable error messages for determining who's using that object. Pouring through the list of retained objects, trying to find the one you're concerned about by looking through ambiguous short names or via the profiler's deep tree hierarchy, is not nearly as straightforward. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
