-- eric miller http://www.w3.org/people/em/ semantic web activity lead http://www.w3.org/2001/sw/ w3c world wide web consortium http://www.w3.org/ On Aug 5, 2005, at 3:41 PM, Stefano Mazzocchi wrote: > While Ryan very successfully chases storms > > http://ryanlee.org/journal/one?journal_id=4008 > > I've been trying to chase leaks, but not water but memory ones. > > I spent endless hours this week understanding how the firefox > internals really work, expecially the XPCOM and XPConnect bridge. > Remember: David wrote the magic xpcom+javascript+java components > that make piggybank possible, I didn't. It's not a lot of code > (maybe a few thousand lines total) but it's incredibly dense > because it requires you to understand all sort of things about the > frameworks/platforms that either call you or you call. So I think I > understand every single line of it and why it's there (and believe > me, some of it it's really not obvious, like when you inject the > Packages object into the XPConnect wrapping object so that the > XPCOM compontent can have access to the java virtual machine, sheesh) > > [btw, thanks to Brian King (that I know watches this) for the > wonderful introduction on XPCOM on the mozdev book!] > > The problem with Piggy Bank is that memory is not freed, new > observers are initiated everytime a new tab is open (I'm beginning > to suspect, everytime a tab is 'changed' because the leak appears > even if you just keep changing between just two open tabs!) and I > have no idea why. > > But I ran into something that is promising: > > http://www.mozilla.org/scriptable/avoiding-leaks.html > > David Baron (one of the super-owners of the mozilla codebase) > explains why XPCOM components written in javascript could very > easily leak memory if not properly done. > > He lists a few sins: > > 1) Don't store temporary objects permanently in global variables > > 2) If you register an observer, remember to unregister it > > 3) Don't create dependency cycles through XPCOM > > 4) Don't store short-lived objects as JavaScript properties of > short-lived DOM nodes > > I think we commit sin #1. I also think we commit #2 because I never > see the components unload functions being called. I doubt we do #3 > and I'm really not sure about #4, but the document cites explicitly > a problem with the 'tabbrowser' that might leak like crazy if not > properly cleaned up after use, so I assume we do this as well. > > Now, what makes my life even more interesting is that not only we > have C++ code calling Javascript code but we also have that > Javascript code calling Java code. > > Fun fun fun. > > The other problem is that I have no clue on how to instrument > firefox itself to trace memory, the memory leaking articles are all > between 2 and 5 years old and they all refer to profiling mozilla, > not firefox.. and I'm running into some walls compiling deerpark > with memory tracing turned on (Brian, any tip on this?) > > Anyway, I'm getting close, at least now I know where to look and > what to look for. I still don't know how to look but I'll figure > that out today, hopefully. > > At the end of the day, it's an interesting and challenging puzzle, > and I like challenges and puzzles... and is giving me a lot more > confidence in the mozilla platform internals (which is a great > thing since I expect mozilla to be used more and more as a platform > in the future and for us to make more plugins for other moz-based > applications, for example thunderbird). > > Anyway, just a report so far, no code to commit, but I'm closing in. > > Wish me luck. > > -- > Stefano Mazzocchi > Research Scientist Digital Libraries Research Group > Massachusetts Institute of Technology location: E25-131C > 77 Massachusetts Ave telephone: +1 (617) 253-1096 > Cambridge, MA 02139-4307 email: stefanom at mit . edu > ------------------------------------------------------------------- > >Received on Fri Aug 05 2005 - 20:23:03 EDT
This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:18 EDT