Fixed TraceMalloc.pm to handle regexps; worked with brendan to identify the pile of JS cruft that was taking up memory. Dug into startup profile a bit more deeply. Couple more rounds of back-and-forth with rfg; looks like we've finally got a patch to gcc that's start to get rid of redundant static data.

Cache design review, redux. More brain dumps from buster. Talk to hyatt briefly about outliner stuff.

Collect profile information on scrolling. Is doing the outliner worth it?

Posted the scrolling profile. Also collected a folder switching profile.

Finally checked in the patch for 61337. Spent some more time banging around a race condition with the proxy code, and found another (apparent) race condition in necko.

Spent a bit of time twiddling with gcc-3.0 in hopes that it might generate tighter code (rth@redhat.com claims the x86 back-end has been re-worked). Initial results (I only looked at libxpcom.so) seem to indicate that the code is bigger than both gcc-2.95.2 and egcs-1.1.2:

   text	   data	    bss	    dec	    hex	filename
 706249	  26084	    900	 733233	  b3031	/export/waterson/seamonkey-opt/mozilla/xpcom/build/libxpcom.so
 740669	  48140	   1580	 790389	  c0f75	/export2/waterson/seamonkey-gcc-2.95.2/mozilla/xpcom/build/libxpcom.so
 778511	  22380	   1000	 801891	  c3c63	/export2/waterson/seamonkey-gcc-trunk/mozilla/xpcom/build/libxpcom.so

Grr.

Started working on a ``layout cheat sheet'' for block and line reflow. Circulated to buster, karnaze, attinasi, rbs, and roc+moz for initial comments.

Spent most of the day poking around at a regression that was caused by a checkin that I super-review'd. Ended up trying to keep my ``layout cheat sheet'' up to date: hopefully a worth-while exercise. Put it up on mozilla.org.

Suggestion to attinasi & pierre to avoid allocation during style context lookup.

Spent several hours digging around the ``frankengcc'' installation trying to figure out why we're crashing. Traced it in to nsAReadableString::EndReading(). Mmm, templates. Looks like a vtable pointer is pointing off into the weeds: need to A-B test with good gcc-2.95.2 to figure out what's going on.

Performance and footprint meeting.

Started another round of trace-malloc gathering, but had to terminate it early.

Talked to thesteve for a while about leak gathering and where we should go.

Spent some time working on getting XUL templates up and running inside of XBL (bug 39054).

Between yesterday and today, I've finally figured out what the problem is: some of the vtables are being added to the .symtab section, but aren't getting a relocation in the .rel.got section. I cooked up a minimal test case that illustrates the problem (but doesn't crash), and forwarded on to rfg.

Checked in fix for proxy code potential deadlock (bug 65146. Put the wraps on 39054 and checked it in.

Updated the block-and-line cheat sheet with feedback from buster et. al.

Spent some time breaking down the nsString and void* data that was appearing at the top of my live object growth reports. Summarized and posted.

Tuesday, February 13, 2001

My checkin for 39054 caused some pretty serious regressions. Had to back it out this morning, but was able to track down what the problem was by this afternoon. Updated the bug and'll hope to have it r='d again soon.

A bit more back-and-forth on the frankengcc.

Got a hacked Boehm GC build up and running to collect data about leaks as we run through my favorite URLs.

Collected a profile on opening a second browser window.

Spent some time looking into DLL loading on Win98. Couldn't get a straight answer from Quantify, so I hand-instrumented xcDll::Load() to watch wall-clock time while loading component DLLs. Looks to be about a third of the time on a fast machine, less on a slower machine. Also spent some time trying to figure out if rebase matters. I think the answer is, “maybe bind matters more.”

Spent some time profiling changes to second-window opening, trying to account for effects from bug 39054. In Quantify, it looks like a slowdown, but using jrgm's wall-clock test it looks like a wash, or possibly a speedup. So, I'm goin' forward baby.

Took another look at winEmbed startup, rebase-ing, and all. It does look like doing a rebase avoids getting us put into the paging file: I saw the page file usage at about 12MB in an un-rebase'd build, and about 8MB in a rebase'd build. I'm surprised that this doesn't account for more time, but maybe buster is right: this'll show up more clearly on a machine with less memory.

Also watched our file I/O. It looks like we load about 2MB of data on startup. We also have a lot of “other” (i.e., not “read” or “write”) activity. Is this us stat()-ing files, maybe?

jrgm mentioned that we're seeing load timeouts on slashdot because we are repeatedly stretching a percentage-width GIF in a percentage-width table. Mmm, fix point! Something to look into.

rickg pointed out Process Explorer, which I'll download and look at next week (so I don't feel guilty about wasting two days of the timebomb).

Spent the day looking at a floater bug. Think I figured out why it's happening; not sure how to fix it yet.

jst and heikki landed their layout factoring stuff, so I am now in the process of updating my ancient seamonkey-content-merge tree. Sent a list of files that need to move around the repository to leaf. Hopefully he'll get 'em moved soon.

Ran a profile on a slow page, and confirmed somebody's (karnaze?) suspicions that it's an {ib} problem: too many calls to ReframeContainingBlock(). Need to figure out how to make stuff work without calling that.

Also took a peek at a page that looked like a hang: this one ended up loading fairly quickly, and then got wedged later on as image width & height arrived. Thought maybe karnaze's work to coalesce table reflows might go a long way here.

leaf juggled the repository files that I needed so I spent the rest of the day working on XUL_CONTENT_MERGE_20010220_BRANCH, trying to move XUL out of RDF so that happy refactoring can begin. It's 95% working: I'll sort out the last couple of bugs while dougt is landing his network stuff tomorrow. Some stuff I noticed:

• Mail folder pane and thread pane don't show up. There's an error about not being able to create the XUL sort service: could have to do with my progID munging.
• On Linux, saw a JS error about ``controllers not defined'' when opening the bookmarks window. I suspect that I may need to fix the MODULE that's being used to create that IDL.
• Couldn't type into composer window on Linux. No obvious error messages.

Landed XUL_CONTENT_MERGE_20010220_BRANCH.

Spent the day figuring out why the edit field wasn't getting events in my {ib} test case for 64670. The problem was silly: there was an eleventh-hour fix to stifle key events to plugins, and the object frame that ended up in the hierarchy ended up stuffing the events! The good news is that I found a couple other bugs along the way: SplitToContainingBlock() was generating a bad frame hierarchy; I wasn't creating a view for aRightInlineFrame; I wasn't dealing with cases where aLeftInlineFrame or aRightInlineFrame might be null. Mmm, mmm, good.

dbaron pointed out that I caused the RDF service to leak: turned out that I had forgotten to call nsXULContentUtils::Finish().

Triaged away old M18 bugs.