RuleSet causes 600 kB of memory fragmentation

RuleSet stores data as a HashMap from AtomicStringImpls to Vector<RuleData>.
When each CSS rule has a different class selector, each Vector is populated
with a single value. When you add the first value to a Vector, the Vector
pre-allocates 16 slots, which means there's 15 * sizeof(RuleData) wasted space.
We're smart and shrink these Vectors down to size, but that shrinkage doesn't
actually results in freeing up memory because of heap fragmentation.

This CL changes how we constructo RuleSet objects. During construction, we use
a LinkedStack, which lets us build each HashMap entry incrementally without
needing to preallocate a large number of moderately sized chunks. After we're
done building the RuleSet, we compact the representation back into Vectors. At
that time, we know exactly how large each Vector needs to be and we can size
them precisely to meet our needs.

This CL has two effects on memory usage:

1) Lower peek memory usage. When building the RuleSet, we no longer
   pre-allocate megabytes of Vector buffers.
2) Lower heap fragmentation. When compacting the RuleSet, we no longer leave
   thousands of holes in the heap.

I measured the impact of this change using CSS extracted from Mobile Gmail. On
the Mobile Gmail CSS, the VmRSS of the content_shell render process is 200 kB
smaller after this CL (measured on Linux).

Additionally, I wrote some synthetic CSS that contained 2000 empty CSS rules
with unique class name selectors. On that case, the VmRSS of the content_shell
render process after loading the page shrinks by 676 kB.

I also measured that the peek memory usage improvement was of a similar scale,
but I unfortunately don't have the data anymore.

R=ojan

Review URL: https://chromiumcodereview.appspot.com/17314010

git-svn-id: svn://svn.chromium.org/blink/trunk@152839 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Don't issue Stop() for spurious command line differences.

The android driver was checking self._current_cmd_line against its
own _android_driver_cmd_line() even though ServerProcess.start() was
setting that value based on the normal cmd_line().

Doing so results in the appearance of different command lines which
causes a ServerProcess.stop() to be issued and tear everything down.

Example:
_android_driver_cmd_line() = ['ContentShell.apk', '--no-timeout',
'--encode-binary', '--enable-hardware-gpu', '--force-compositing-mode',
'--enable-accelerated-fixed-position', '--dump-render-tree', '-']

_cmd_line() = ['adb', '-s', u'04aa0e7cdd540dac', 'shell']

Now a single content_shell instance is responsible for running all
the tests!  Much faster :)

BUG=232044
TEST=content_shell tests use a single instance.

Review URL: https://chromiumcodereview.appspot.com/17502004

git-svn-id: svn://svn.chromium.org/blink/trunk@152840 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove unused attachChildrenLazily method and make attach/detachChildren private

No one should be manually trying to attach or detach all their children so there's
no reason for these methods to be public.

In doing this I realized that attachChildrenLazily is not used and can be removed.

I also realized that we were detaching all our children before the ShadowRoots which
is sad since the InsertionPoints will call detach() on them as well, and then when we
call ContainerNode::detach at the end of Element::detach we'll go detach them again!
This patch makes it so we only go through and detach them twice instead of three times.
In the future we should figure out a way to only do this once.

Review URL: https://chromiumcodereview.appspot.com/17512006

git-svn-id: svn://svn.chromium.org/blink/trunk@152841 bbb929c8-8fbe-4397-9dbb-9b2b20218538
The test failure is caused by firing timeout event before document loaded.

More specifically, step1() tries to set caret position by mouse down, but it doesn't set caret position, because there are no nodes. This reason why below lines are missed in failed result:

EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 5 of #text > PRE > BODY > HTML > #document to 5 of #text > PRE > BODY > HTML > #document toDOMRange:range from 5 of #text > PRE > BODY > HTML > #document to 6 of #text > PRE > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=editing%2Fselection%2Fdoubleclick-crash.html

BUG=241855
R=jochen@chromium.org

Review URL: https://codereview.chromium.org/17471003

git-svn-id: svn://svn.chromium.org/blink/trunk@152842 bbb929c8-8fbe-4397-9dbb-9b2b20218538