Jun 12

performant concurrency

The most important conclusion from this foray into history is that concurrency has always been employed for one purpose: to improve the performance of the system. This seems almost too obvious to make explicit—why else would we want concurrency if not to improve performance?—yet for all its obviousness, concurrency’s raison d’être is increasingly forgotten, as if the proliferation of concurrent hardware has awakened an anxiety that all software must use all available physical resources. Just as no programmer felt a moral obligation to eliminate pipeline stalls on a superscalar microprocessor, no software engineer should feel responsible for using concurrency simply because the hardware supports it. Rather, concurrency should be thought about and used for one reason and one reason only: because it is needs [sic] to yield an acceptably performing system.

–from Real-World Concurrency by Bryan Cantrill and Jeff Bonwick

Jun 12

lessons learned while filing bugs

When I tell people that I and my entire team at Mozilla work remote, they often ask, “How do you keep track of everything people are doing?”  I tell them about Bugzilla and anything that needs fixed goes into it as a bug; bugs aren’t just for software problems, but hardware requests, account requests, office maintenance, the list goes on.  A bug is anything that prevents you from getting your work done.

Despite extolling the virtues of filing things, large and small, in Bugzilla, I (re?)learned two lessons about filing bugs this week:

  • Even if you think something is totally obvious, file a bug.  I needed to modify the Android mozconfigs this week because they weren’t turning on telemetry support, like our desktop mozconfigs.  In the process, I became disgusted with how much copy-and-paste there is between our mozconfigs and thought, “Surely, there is a bug out there already on this goop.”  I even asked one of my colleagues, Mike Hommey, whether there might be a bug on this already.  It turns out there wasn’t one, but there is now.  I shouldn’t have even asked Mike; I should have searched Bugzilla a bit and filed something if I couldn’t find a plausible match  Worst-case, somebody would mark my bug as a duplicate and I would be connected with people and/or possible attempts at fixing the bug already.
  • If something looks like a bug, file a bug.  Back in March, I made it harder to get certain kinds of Telemetry histograms wrong.  In the bug, I noted several histograms that were wrong, but didn’t bother to do anything about them.  “Too much work for too little gain,” I said.  Turns out that the networking team has been working with bad data on cache Telemetry because of one of the aforementioned histograms being wrong.  That problem could’ve been fixed several months ago!  My mistake; I should have filed each and every one of those histograms as a bug and let the relevant teams decide what to do about them.  Even if you think it’s harmless, file a bug.  Worst case is somebody tells you that it is harmless and you come away enlightened.  (And just in case you’re wondering, yes, there is a bug to make those histograms even harder to get wrong.)

And as always, please remember to follow Bugzilla’s rules of etiquette when filing bugs.

Jun 12

about:memory statistics improvements

The three major memory costs to rendering webpages in Gecko are layout, the DOM, and JavaScript.  Only the last of these has a detailed about:memory breakdown.  Layout has a few subcategories, but likely as not, layout/arenas is one big opaque number, and DOM just sits as a big blob-o-stuff.

Over the past two weeks, I’ve been working to improve this state of affairs.  DOM’s numbers have been made more transparent by splitting out the numbers by the type of DOM node.  Admittedly, this isn’t perfect, as now you have several semi-opaque blobs, but it gives you a slightly better idea where the memory is going.  Additionally, a few more things are getting counted in those DOM numbers, like some on-the-side datastructures Gecko’s DOM engine keeps around.

Layout has received the most work, however.  We now display stats for individual frame types and common objects allocated in layout’s arenas, which can be helpful in diagnosing page performance problems (bug 686795 comment 10 and comment 23).  Please note that in the stats for these frames and objects, we’re not measuring any substructures contained in them, some of which could be quite significant.  That’s a (potentially tricky) job for later.