Most of the time, a lot of the WebIDL interfaces are never used with Xray wrappers.
We still always initialise the necessary PropertyInfo arrays whenever they're used
normally (not through Xray wrappers). I think we should postpone that initialisation
until we're actually going to use them with Xray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D114402
Most of the time, a lot of the WebIDL interfaces are never used with Xray wrappers.
We still always initialise the necessary PropertyInfo arrays whenever they're used
normally (not through Xray wrappers). I think we should postpone that initialisation
until we're actually going to use them with Xray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D114402
I had to draw this on paper to understand how all this stuff works. Might as
well save someone else (possibly me) the trouble in the future.
Differential Revision: https://phabricator.services.mozilla.com/D90668
I had to draw this on paper to understand how all this stuff works. Might as
well save someone else (possibly me) the trouble in the future.
Differential Revision: https://phabricator.services.mozilla.com/D90668
WeakRef targets that are wrappers to DOM objects are preserved when the WeakRef is created. This checks whether the wrapper is still preserved in deref() and if it is found to have been released, the target is cleared.
The patch adds a new DOMJSClass hook to deal with getting the wrapper cache for non-nsISupports objects.
Differential Revision: https://phabricator.services.mozilla.com/D78061
JSClass contained void* members corresponding to the internal pointer members of js::Class. This stores the internal members in JSClass and removes js::Class.
This leaves js::Class aliased to JSClass while we remove references to it. I also aliased Jsvalify and Valueify into global scope temporarily to make this compile. These get removed in the following patches.
I had to remove a few functions which now don't compile with js::Class being the same type as JSClass.
Differential Revision: https://phabricator.services.mozilla.com/D41983
--HG--
extra : moz-landing-system : lando
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
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
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
Peter Van der Beken
Tom Schuster
Dorel Luca
Simon Giesecke
Nicholas Nethercote
Mihai Alexandru Michis
Jeff Walden
Jon Coppeard
Boris Zbarsky
Yoshi Cheng-Hao Huang
Sylvestre Ledru
Jan de Mooij
Arnaud Bienner
Margareta Eliza Balazs
Ting-Yu Chou
Andrea Marchesini
Alexandre Lissy
Chris Peterson
Jonathan Watt
Ms2ger
Kan-Ru Chen