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 - 19:37:53 EDT