Threaded HTML parser enabled on trunk

[Adam Barth]

== Summary ==

Eric Seidel, Tony Gentilcore, and I have been working on
multi-threading our HTML parser (see [1] for a design diagram).
Today, we enabled the threaded parser on trunk, which means it will be
enabled in tomorrow's Canary.

== Performance ==

The threaded HTML parser has two performance benefits: (1) reduced
jankiness by moving work off the main JavaScript thread, and (2)
improved page loading speed through pipelining.

We're measuring jankiness improvements with the maximum pause
attributable to the HTML parser when loading web pages on a Nexus 7.
Using the Telemetry performance testing framework [2], we see a 40%
reduction in parser-induced jankiness on the Top25 page set.

For page loading speed, we're using the normal page cyclers [3]. On
dual-core machines across operating systems, the threaded HTML parser
is roughly a 5% improvement on intl1, a 3.5% improvement on intl2, and
an 8% improvement on moz. On single-core machines, we see a 1.5%
improvement.

We don't fully understand why the threaded parser is faster on
single-core machines. My hypothesis is that tasks that want to run on
the main thread can preempt the threaded parser because the kernel
preemptively multitasks threads. With the non-threaded parser, those
tasks need to wait in the message loop because the non-threaded parser
is blocking the main thread.

== Troubleshooting ==

If you run into problems in with a Canary build that you think might
be caused the threaded HTML parser, you can try running with
--disable-threaded-html-parser. If you can reproduce the problem with
the threaded parser and not without the threaded parser, please file a
bug and CC Eric, Tony, and me. Hopefully everything will go smoothly,
but I suspect we've screwed up a few things at least. :)

Happy hacking!
Adam

[1] https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit?usp=sharing
[2] http://www.chromium.org/developers/telemetry
[3] http://chromium-perf.appspot.com/