> I'd like to repeat something I wrote in another message: "...a very > important point that most developers ignore or forget. GC is an undecidable > problem, meaning that there will always be cases where a human being needs > to figure out when in the object lifecycle it is not longer needed and > either free it in languages where that's possible or make it collectable in > languages with a GC. There will be such cases even in languages where there > are weak references. " > And when such a case will be found, what will be the solution? Adding a new > subtler language construct which exposes a bit more of the GC? > > JavaScript has an history of being the language of the client side where a > web page lives for a couple of minutes; leaks were largely unnoticeable > because navigating or closing a tab would make the content collectable > (well... except in crappy version of IE in which JS content could make > browser-wide leaks -_-#). > As soon as we have long-running JavaScript, we have to start caring more > about our memory usage, we have to question what we assumed/knew of > JavaScript. The GC does maybe 80-100% of the job in well-written complex > code, but we must never forget that the GC only does an approximation of an > undecidable problem. > In applications where memory matters a lot, maybe a protocol like .dispose > will become necessary.
I agree that there are scenarios where .dispose() or a similar protocol may be come necessary; in those scenarios it would be great if JS had some mechanism that could be used to simplify the proper use of the protocol. Given that the need for Weak References in many scenarios would be reduced because a partially (or wholly) automatic implementation of that protocol can make it much easier to use the protocol correctly. As I mentioned earlier, I think 'using' in C# is a relatively simple feature that lets you express this, and function scoped values with destructors like in C++ are a great way to express this since you can increment a refcount in the constructor and decrement it in the destructor. The downsides still remain, though - refcounting (or other forms of non-GC management) add some overhead to all the code that uses objects managed with those lifetime policies. Manual refcounting requires the programmer to think about every function to understand where refs should be added/removed and adds noise to the code; explicit .dispose() without refcounting requires a programmer to have a global understanding of his/her application in order to determine the correct location to call it, which is very difficult for large applications. > About weakrefs, I've read a little bit [2][3] and I'm puzzled by one thing: > the return value of get is a strong reference, so if a misbehaving component > keeps this strong reference around, having passed a weak reference was > pointless. The return value is a strong reference because otherwise you'd have to write a check on every line to see if the object had expired in between statements. It'd also mean that any function you passed the weak object to would have to perform the check. You can think of a weak reference as similar mechanically to a refcounted object: You 'acquire' a reference to the object, hold onto it a while to use the object, then 'release' the reference. In refcounting this is done with ++/-- to prevent destruction; for weak references, you do this by converting the WR temporarily into a strong reference and then discarding it. -kg _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
