Re: Chasing leaks...

From: Eric Miller <>
Date: Fri, 5 Aug 2005 16:26:35 -0400

Thanks Stefano! I certainly appreciate the update, but even more the
Herculean effort it seems you've undertaken to fix this problem.
Sounds like you're close - keep up the excellent work!

eric miller                    
semantic web activity lead     
w3c world wide web consortium  
On Aug 5, 2005, at 3:41 PM, Stefano Mazzocchi wrote:
> While Ryan very successfully chases storms
> 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:
> 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