4 ms·
If you have reference counting across GC boundaries, you can easily create memory leaks because of reference cycles, e.g. GC 1 cannot release object 1 because i
by majewsky 9y ago
If you have reference counting across GC boundaries, you can easily create memory leaks because of reference cycles, e.g. GC 1 cannot release object 1 because it references object 2, and vice versa. (Unless you only allow refs to go one way.)
- masklinn 9y agoGreat now I get flashbacks to 2005. IE6 had exactly that issue, the DOM was implemented using COM which has its own GC (refcounting) separate from the regular JS runtime. If you created a cycle between DOM and JS by, let's say, adding an event handler to a DOM node — thankfully that's something you'd never do when developing web pages & applications — you'd start leaking memory which would survive across page reloads. There was actually a bit of software called Drip, it was just a webview wrapper (technically an MFC app with a browser COM component), you'd launch it, open your page, click the "blow memory" button and it'd reload the page over and over again listing elements which had survived between reloads.