Please try -- such experiments are interesting. But even if this experiment is successful, I hope and expect that we'll have weakrefs and post-mortem finalization in ES7. They are needed for many other things, such as distributed acyclic garbage collection (as in adapting the CapTP ideas to distributed JS).
On Fri, Nov 8, 2013 at 8:57 AM, David Bruant <[email protected]> wrote: > Le 08/11/2013 17:09, Jason Orendorff a écrit : > > (As a bonus, the weirdness will happen in one implementation and not >> another, and you and your users will blame the implementation. So >> there will be pressure on implementers to reduce the nondeterminism by >> doing GC more frequently—which trades off against other performance >> measures.) >> > Super-bonus: Heisenbugs (bugs that happen in prod, but not while debugging) > https://en.wikipedia.org/wiki/Heisenbug > > > And in this case, it all seems unnecessary. There is apparently >> already explicit code for both removing B and C, and later coping with >> their disappearance (since the weak reference may go null). That code >> could just as easily set a bit on B and C marking them as removed, and >> then test that in the chasing code. >> > Agreed. In a way, Kevin conceded it when he wrote in an earlier message: > > I had to manually remove the event listeners at an appropriate time (and >> finding an appropriate time can be difficult!) >> > And this looks very much like a software engineering issue, not a language > issue. Maybe we (JavaScript developers!) should invest in better memory > tooling see how far it gets us. We have fantastic tooling for studying time > perf (Chrome has 2 types of profilers and the timeline view to help with > the 60fps, Firefox and IE11 getting there too), how come we're still doing > low-level heap snapshots for memory perf? Is space fundamentally that much > harder to study than time? > > Taking the tooling road first, worst case, we throw the tooling away... > not an option when a feature is in the wild. > > Let's try at least? > > David > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
