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.
I'm pretty sure I've committed all the four sins... I'll go to my room
and recite some RFC ten times now.
> 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.
>
Good luck, Stefano! Sorry I can't be there to help you out! :-( Just a
thought, maybe you can use Greasemonkey to automate creating and
switching between tabs, which might help with reproducing the leak as
you add the PB code back bit by bit?...
David
Received on Sat Aug 06 2005 - 01:31:19 EDT