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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
