Posted by: benoitgirard | March 25, 2013

Profiler @ Snappy Work Week

Last week I attended the snappy work week with goal of syncing up with Julian Seward and Mike Hommey regarding the new Breakpad unwinding feature, planning and prioritizing new feature work. I also got lots of valuable feedback. Here’s what you need to know if you’re a frequent user of the Gecko Profiler.

Breakpad Unwinding (Mobile)

For the last few months Julian has been spearheading integrating the breakpad unwinding feature to the Gecko Profiler. This turned out to be a very complicated task because we’re trying to use Breakpad for something it wasn’t meant to do. This work is now landed but it only works in a very specific build configuration (unwind tables, unpacking the libraries, no elfhack). We are currently working on addressing these problems to make it work in the default Nightly configuration.

Our current target is to use Breakpad unwinding in the Linux May 1st nightly. A week later have the Fennec nightly support breakpad unwinding. I’m hoping afterwards to support Breakpad unwinding on B2G central (not b2g18) but I expect this may be difficult on a memory constraint phone so I currently have no estimate for this at this time.

If you looked at the code for the profiler you may notice TableTicker1+TableTicker2. During the work week we refactored the code significantly to address this code duplication while resolving inconsistencies between the frame-pointer unwinder and the Breakpad unwinder.

Multi-Thread/Multi-Process Support

The profiler will soon support showing samples and timelines for multiple threads. This is already somewhat supported on B2G if you use a script written by Vlad. This will become easier as we begin to add multi-thread support to all the platform backends (already in progress for Mac and Linux) thanks to the help of James Willcox. This ties in heavily with the next two section (IPDL/Plugins).

Plugin Support

Plugin issues have long been identified as the single biggest contributor to responsiveness issues by Vladan‘s Chrome Hang work. This was the topic of the break out discussion headed by Benjamin Smedberg. We discussed a plan of attack by adding profiling to the plugin process which should land this week but require a manual step. This feature will let us know what’s going on in the plugin process when the browser’ main thread is waiting for an IPC response (and vice versa). It will improve as we add profiling support for profiling IPDL messages.

Flash Profiling

Flash initializing audio on plugin-container startup.

IPDL Message Support

During the week we decided to add profiler labels to each IPDL call automatically. That will help where the unwinder isn’t supported but doesn’t give us the data we need. In particular we’re looking to get better data about how IPDL messages are queued, how long they take to get dequeued and to processed. Combined with the Plugin support this should help us diagnose complex issues with our plugin-container or get better data on how particular plugins are hurting the responsiveness of the browser. Georg Fritzsche has an excellent plan in bug 853864 on how to implement this.

About these ads

Responses

  1. Could you describe what this breakpad unwinding feature does?

    • It will provide full stack information on mobile like we currently get on windows/mac.

    • It’s mostly just architectural work at this point, but it replaces the use of libunwind in many cases, which has been really unsuitable for the profiler. Despite requiring a bit of rework to make it fit, the Breakpad code turns out to give us more flexibility to avoid the sorts of problems we were hitting with libunwind.

  2. I’m very psyched about the multiple thread support! The e-mail app in Gaia is moving most of our back-end logic into a worker thread, and we’re really going to miss the ability to profile to see what it’s doing.

    Is it possible to link to Vlad’s script? I had checked out some of the bugs the other day, and I also say it referenced as existing, but was unable to find it as an attachment or a linked URL or the like. Thanks!

  3. Will the support for profiling multiple threads also allow background JS compilation to be re-enabled when the profiler is active? I can’t remember the bug number for this, but I recall that was disabled a while back to quench profiler related crashes.

    • They are not related. But re-enabling that feature is important because we want to be profiling exactly what we are running.

  4. [...] Benoit Girard, Georg Fritzsche and Benjamin Smedberg are working on uncovering the causes of some of these hangs by adding profiling support to the plugin-container.exe process (bug 853358 and bug 734691) and exposing IPC message information to the profiler (bug 853864 and bug 853363). You can find Benoit’s write-up here. [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: