This patch enables sharing of an nsAttrValue's MiscContainer between nodes for style rules. MiscContainers of type eCSSStyleRule are now refcounted (with some clever struct packing to ensure that the amount of memory allocated for MiscContainer remains unchanged on 32 and 64 bit). This infrastructure can be used to share most MiscContainer types in the future if we find advantages to sharing other types than just eCSSStyleRuley. A cache mapping strings to MiscContainers has been added to nsHTMLCSSStyleSheet. MiscContainers can be shared between nsAttrValues when one nsAttrValue is SetTo another nsAttrValue or when there is a cache hit in this cache. This patch also adds the ability to tell a style rule that it belongs to an nsHTMLCSSStyleSheet, with appropriate accessor functions to separate that from the existing case of belonging to an nsCSSStyleSheet.
The primary use case is to reduce memory use for pages that have lots of inline style attributes with the same value. This can happen easily with large pages that are automatically generated. An (admittedly pathological) testcase in Bug 686975 sees over 250 MB of memory savings with this change. Reusing the same MiscContainer for multiple nodes saves the overhead of maintaining separate copies of the string containing the serialized value of the style attribute and of creating separate style rules for each node. Eliminating duplicate style rules enables further savings in layout through style context sharing. The testcase sees the amount of memory used by style contexts go from over 250 MB to 10 KB.
Because the cache is based on the text value of the style attribute, it will not handle attributes that have different text values but are parsed into identical style rules. We also do not attempt to share MiscContainers when the node's base URI differs from the document URI. The effect of these limitations is expected to be low.
These are the manual fixes that the ensuing auto-generation can't deal with. Some of them
just fix up formatting (such as Components.\nFoo, so that subsequent auto-generation can
work better).
In Bug 785057, the implementation of mozGetMetadata was changed
to propagate a failure to define a new object property through
the return value of the nsDataHashtable interator. It turns out,
EnumerateRead returns the number of items processed, not the
last PLDHashOperator result. The upshot of which is that
the method returned an error if and only if only one tag
was processed.
Instead, carry and error flag in the iterator state, and check
that for failure.
Return PL_DHASH_STOP if JS_SetProperty fails, and check
the return code of the enumerator to propagate the failure
back to javascript through the return value of mozGetMetadata.
In addition, use JS_DefineProperty in mozGetMetadata so
web content can't intercept and alter our creation calls.
JS_SetProperty() will define a new property if it doesn't
exist, but it will also call any existing setters, in
particular those on Object.prototype. This is confusing
for an object that created by a platform object method
from internal data.
