What I did this week
--------------------
- when thru every single line of code in both greasemonkey and
piggybank to find out differences
- instrumented the heck out of piggybank to understand what's going on
- created a branch with the 2.0.x code and now trunk hosts 2.1.x, a
refactored, cleaned-up, heavily instrumented version of piggy-bank
- fixed a few CSS warning and syntax errors helped with deer-park
chrome-to-javascript-console help (which also allowed me to remove a lot
of our own try/catch code which makes our code a lot cleaner)
What I found out
----------------
- PB was listening to too many browser events (which included loading
of every fragment of every xul page, which I think is the reason why the
browser felt a little less responsive when PB was loaded in). Now it
listens only to document loading events, therefore the browser seem to
behave a little faster when PB is not involved (NOTE: this has nothing
to do with the memory leak and it might be subjective.. for sure it
doesn't make it worse).
- removed an XPCOM components (nsInfoUtil), and moved the
functionality into the overlay controller code in javascript (now those
functions don't use java anymore): the less XPConnect components we
initialize the faster the browser start.
- there were several xpcom+javascript reference cycles that weren't
cleaned up. I have disposed all that I could find but I haven't tested
whether the memory leak is still there or not (planning to do this
next). I suspect there is some major screwup in the way the collector
hashtable is managed, so there is more to do.
- found out that calling the overlay master-overlay.xul is not a good
idea (this is what seems to create some of the this.docShell has no
properties exception in the tab browser code), therefore I renamed it
browser.xul (and also added the new chrome.manifest to make deerpark
happier), now all those nasty and random this.docShell exceptions went
away (yey!)
- changed the UUID of piggy-bank also avoids the problem with earlier
versions of firefox that had a problem in updating an extension in case
the main overlay file changed name! The drawback is that you can have
two different versions of piggybank installed at the same time, which
might create confusion and conflicts. If you install Piggy Bank 2.1.x I
suggest you to manually uninstall Piggy Bank 2.0.x first (don't worry,
the data is never erased and will be picked up by the new piggy-bank)
What is left to do
------------------
- do a complete trace of pb when dealing with tons of tabs and analyze
the resulting trace to see where is the leak and what is causing it (I
suspect it's a combination of the collector hashtable + xpcom reference
cycles that aren't cleaned-up, especially the Packages object that we
pass to the xpcom components for them to have access to liveconnect )
- understand how to react on the dom *after* all other extensions have
messed with it (greasemonkey, adblock and so on).... might not as simple
as it sounds though, since we have a way to register a listener but
never a way to register a listener to trigger 'after' another.... I
wonder if the order of the extensions in the extension pane is actually
influencing how registered listeners are called.. if so, it's enough to
have piggy-bank last in that list to achieve that. I need to try this out.
--
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 Mon Aug 15 2005 - 17:38:44 EDT