js::Class op are often all null. And when they're not all null, they're often
duplicated among classes. By pulling them out into their own struct, and using a
(possibly null) pointer in js::Class, we can save 114 KiB per process on
64-bit, and half that on 32-bit.
* * *
imported patch separate-ClassOps-2
--HG--
extra : rebase_source : bd751bf247e9491c1966a123dbeffa573657dfb1
js::ClassExtension is often all null. When it's not all null, it's often
duplicated among classes. By pulling it out into its own struct, and using a
(possibly null) pointer in js::Class, we can save 17 KiB per process on
64-bit, and half that on 32-bit.
--HG--
extra : rebase_source : eb78ade09ce268e886d091f6cbc38d7e5e912527
This patch makes NativeProperties variable-length and reduces static data by
110,336 bytes on 64-bit, and half that on 32-bit.
MozReview-Commit-ID: 2etZ5AnEhgO
--HG--
extra : rebase_source : 6a167b64df7da3c6940114782fe08337f04a694d
js::ObjectOps is often all null. When it's not all null, it's often duplicated
many times among classes. By pulling it out into its own struct, and using a
(possibly null) pointer in js::Class, we can save 208 KiB per process on
64-bit, and half that on 32-bit.
--HG--
extra : rebase_source : 5be8fe45f652392571b8a6d7b63777cbafba6ae4
Note that this does not take into account the exposed/enabled state of the
relevant properties. This should be OK, I hope. Taking that state into account
would be rather annoying, unfortunately. We could make codegen fail if
something is conditionally exposed and unscopable, if desired...
The fields in Prefable relating to disabling are usually all zero. This patch
moves them into a new struct PrefableDisablers. This reduces static data size
by 92 KB, which applies to every process. It might also make isEnabled() faster
because the common case only involves one test instead of two.
--HG--
extra : rebase_source : 004eb8221e23b741c4837dd95af93e437edb4587
This matters when a [Cached] attribute appears on an interface, call it C,
which is a consequential interface for both A and B. There is no a priori
reason that A and B would have identical numbers of their own [Cached]
attributes, which will come before the members of consequential interfaces in
the member array, so in general the attribute may have different slot indices in A
and B.
The approach taken here is to keep things simple and make the slot index of an
interface member either None or a dict mapping interface name to the slot
index. In the common case of only one interface being involved this is a
little wasteful, but it keeps things simple for consumers, and one extra dict
per [Cached] attribute is not a big deal in the grand scheme of the data
structures the Web IDL parser produces. Another option would be to store None,
a number (if there is only one interface involved), or a dict (if there are
several interfaces involved). If we did that, we'd probably want to add some
method to get the slot index for a given interface, because the logic for doing
that would get a bit more complicated.
nsWrapperCache expects the object it stores to have an ObjectMoved op that will
notify the wrapper cache when the object is moved. SpiderMonkey promises don't
have a way to do this.
The XPCConvert changes are needed to allow code that passes around Promise
objects as nsISupports to continue working instead of ending up with
double-wrapped nsISupports (XPCWrappedNative for an nsISupports XPCWrappedJS)
around the SpiderMonkey Promise.
The idea is to not define a "Promise" property on the global and not generate
any of the methods, since SpiderMonkey will implement all of those, but to keep
some of the conversion to/from JS logic and the IDL parser validation bits that
we have right now. Once we can assume SPIDERMONKEY_PROMISE we can probably
change how the "Promise" identifier is handled by the IDL parser and how the
resulting type is handled by codegen, but for now we're aiming for minimal
changes.
