Bug 118015 – RuleSet causes 600 kB of memory fragmentation

• Status: NEW
• Component: CSS

[Ryosuke Niwa]

Consider merging https://chromium.googlesource.com/chromium/blink/+/c3a7797e3cde2c2dbe04b2c54d54740db169e966

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.