Current codegen list the methods for clearing cached attribute values in both
chrome only unforgeable methods and chrome only normal methods, but they should
exist only in the normal ones.
MozReview-Commit-ID: Il2JvCLZ2v3
--HG--
extra : rebase_source : 21b9c715c921c4ac7f6ed4c235ee79a3628162bd
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
There are several places in the WebExtensions framework where we currently
need to repeatedly serialize and deserialize structured clone data as it
passes through message managers, which can lead to significant performance
issues.
This helper class lets us serialize a value directly from the source extension
context into an opaque blob, and then directly deserialize it into the target
context on the other end, with no X-ray overhead or clones into privileged
scopes in-between.
MozReview-Commit-ID: 4QzHi89onxc
--HG--
extra : rebase_source : 2ec196ca9ce9be90b7eadf136c938373ac7d3fdd
Bill, can you please review the binding code? Shane and zombie, can you please
review the content script matching?
MozReview-Commit-ID: IJB5s0a7r7S
--HG--
extra : rebase_source : 4026105b8c04e6b88c9be8cf76898fca26f1c3e0
Bill, can you please review the binding code and the general sanity of the
platform code? Andrew and zombie, can you please review the policy logic and
tests?
As in part 1, this aims to reduce the overhead of our extension policy logic
by making it directly available to native code with as little JS and XPConnect
overhead as possible.
MozReview-Commit-ID: 40m1wSEYtBo
--HG--
extra : rebase_source : c03834791707f78431440af9b88035ab03dc9564
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
The only difference between proxies and non-proxies is that proxies only support
up to MAX_FIXED_SLOTS slots all told (reserved plus private slot). SpiderMonkey
already has static asserts to make sure we don't ask for too many reserved slots
on a proxy.
All DOMProxyHandler::ClearExternalRefsForWrapperRelease now does is clear a backpointer to the expando, and that's handled during reflector finalization already.
