With most of the JS components converted to static registration, the string
arena and component hashtables are much smaller than the minimum space we
allocate for them.
Differential Revision: https://phabricator.services.mozilla.com/D18474
--HG--
extra : source : 81dc12cc9257ba9c8f2eef578d99b142220b37a3
extra : histedit_source : 6f64bcd954cbc4db6970acfb5ed81717c739d13f
With most of the JS components converted to static registration, the string
arena and component hashtables are much smaller than the minimum space we
allocate for them.
Differential Revision: https://phabricator.services.mozilla.com/D18474
--HG--
extra : rebase_source : 94d3f269c7d5cc08608f7e46640c6e3c175cf585
The static XPCOM manifest format makes it easy to define a component in a
single place, without separate contract ID and CID macro definitions in
headers, and variable constants in module files. Without any other changes,
however, those macros are still required in order to create instances of or
retrieve services for the component.
This patch solves that problem by allowing component definitions to include an
explicit component name, and adding helpers for each named component to
Components.h:
mozilla::components::<Name>::CID() to retrieve its class ID.
mozilla::components::<Name>::Create() to create a new instance.
mozilla::components::<Name>::Service() to retrieve its service instance.
These getters have the benefit of doing full compile-time sanity checking,
with no possibilty of using a mistyped contract ID string, or a macro constant
which has gotten out of sync with the component entry.
Moreover, when possible, these getters are optimized to operate on module
entries directly, without going through expensive hash lookups or virtual
calls.
Differential Revision: https://phabricator.services.mozilla.com/D15037
--HG--
extra : rebase_source : ab07ef6a7ad8b26cd4e1901d3365beeb8c22ec3b
extra : source : 929fd654c9dfc3222e1972faadea3cc066e51654
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 903a6f31c6290d0090e6765e0e317d1f749c5855
extra : source : b8d2dfdfc324c53ce5aacc822ce52d4e2bfdc31a
Currently, when we build the component registry at startup, we exclude any
entry with a process selector which doesn't match the current process. When we
switch to static lookup tables, however, that check is going to have to happen
for every lookup, since we can't alter the table at runtime.
That may not matter much, given how expensive the rest of the component lookup
code is relative to ProcessMatchesSelector, but it's also easy and cheap
enough to generate a lookup table for all possible ProcessSelector values, and
do a quick index check instead.
Differential Revision: https://phabricator.services.mozilla.com/D15033
--HG--
extra : rebase_source : 33bb395f3eaa6522b18dbdb6e415b5287add86cd
extra : source : dd00365ebb55a06b4d6896bc86dd0fc94482d805
The current implementations of GetService are slightly different for contract
IDs than they are for CIDs, but I'm pretty sure that's unintentional.
This patch factors out the common parts of the two implementations, which
should prevent them from diverging in the future, and avoids the need to make
the same changes in multiple places in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D15032
--HG--
extra : rebase_source : fceab9df2879f8e02c81009ab3d8c754c9f14677
extra : source : 538e40c5ee1336a7ba467f0f4128dcddf97ef75d
The static XPCOM manifest format makes it easy to define a component in a
single place, without separate contract ID and CID macro definitions in
headers, and variable constants in module files. Without any other changes,
however, those macros are still required in order to create instances of or
retrieve services for the component.
This patch solves that problem by allowing component definitions to include an
explicit component name, and adding helpers for each named component to
Components.h:
mozilla::components::<Name>::CID() to retrieve its class ID.
mozilla::components::<Name>::Create() to create a new instance.
mozilla::components::<Name>::Service() to retrieve its service instance.
These getters have the benefit of doing full compile-time sanity checking,
with no possibilty of using a mistyped contract ID string, or a macro constant
which has gotten out of sync with the component entry.
Moreover, when possible, these getters are optimized to operate on module
entries directly, without going through expensive hash lookups or virtual
calls.
Differential Revision: https://phabricator.services.mozilla.com/D15037
--HG--
extra : rebase_source : db7fe00fe80677a6a42d8136fd4505a02e330495
extra : absorb_source : ec11e22825befcd6fa4e96ffa81cd1c1b23e3bef
extra : histedit_source : 650e8e98235df5d757f3fa725bad390e9c094c34
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 8d02ff3b67b8078d1ac837d8c12f54786155c6b6
extra : absorb_source : 0fe36ca220c9270e634abf5b1f320a01878e0ce7
extra : histedit_source : 51521ceae2c1b3e4e8bf63d4ed1e2e67e9468780
Currently, when we build the component registry at startup, we exclude any
entry with a process selector which doesn't match the current process. When we
switch to static lookup tables, however, that check is going to have to happen
for every lookup, since we can't alter the table at runtime.
That may not matter much, given how expensive the rest of the component lookup
code is relative to ProcessMatchesSelector, but it's also easy and cheap
enough to generate a lookup table for all possible ProcessSelector values, and
do a quick index check instead.
Differential Revision: https://phabricator.services.mozilla.com/D15033
--HG--
extra : rebase_source : fa6c764c2acd68dbe620e5a0779c6c58724ea209
The current implementations of GetService are slightly different for contract
IDs than they are for CIDs, but I'm pretty sure that's unintentional.
This patch factors out the common parts of the two implementations, which
should prevent them from diverging in the future, and avoids the need to make
the same changes in multiple places in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D15032
--HG--
extra : rebase_source : 591d854d604dc7597dbfe5438bfbd0af98224c5b
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : source : 5fb0b7746a5d56563b471e3061ccca124ea45485
extra : absorb_source : 275f5d4dc2c02e3d0391ed16e8690dac1e601758
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : rebase_source : 8d41a3fc5bc1ffe88af998bf9a0ba9ac3331a085
The sStaticModules list is, practically speaking, a copy of the list
of components we already have in libxul, augmented at runtime with
a few other components for tests (for gtest and xpcshell). We don't
actually need to keep that copy in memory. We can instead just use the
pointers in libxul directly to register them to the component manager,
and use a separate list, only for those extra components when they need
to be registered.
--HG--
extra : rebase_source : 1a32c95312d8577c99823adea8dbc0b022c286b2
This patch removes C++ code related to reading in XPT information from
files. (Code related to packaging XPT files will be removed in the
next patch.) This includes code in the manifest parser, in addition to
the actual code for parsing files.
XPT information is now loaded directly from a single static data
structure, XPTHeader::kHeader, which will be automatically generated
at compile time from .idl files (via .xpt files). Note that the script
to do that is not added until part 6 of this patch series, so linking
will fail on parts 2 through 5.
I inlined XPTInterfaceInfoManager::RegisterXPTHeader into the ctor,
because that is the only caller. It feels like the lock there should
not be needed any more, but I left it alone for now.
The forward declaration of XPTArena in xptiprivate.h is needed because
it was being bootlegged via xpt_xdr.h. Some of the data structures in
reflect/xptinfo/ (which wrap the xpt_struct.h data structures) are
still allocated using XPTArena. Hopefully we can get rid of that in
followup work.
I also deleted a lot of comments in xpt_struct.h that talk about the
on-disk format. I also deleted checking of the major version number,
because that should not matter when the XPT information is baked into
the executable.
MozReview-Commit-ID: 6NJdaCWRBhU
--HG--
extra : rebase_source : 6512a05f2a8bee1e6e6b0423d2cb376d8c34728b
This patch removes C++ code related to reading in XPT information from
files. (Code related to packaging XPT files will be removed in the
next patch.) This includes code in the manifest parser, in addition to
the actual code for parsing files.
XPT information is now loaded directly from a single static data
structure, XPTHeader::kHeader, which will be automatically generated
at compile time from .idl files (via .xpt files). Note that the script
to do that is not added until part 6 of this patch series, so linking
will fail on parts 2 through 5.
I inlined XPTInterfaceInfoManager::RegisterXPTHeader into the ctor,
because that is the only caller. It feels like the lock there should
not be needed any more, but I left it alone for now.
The forward declaration of XPTArena in xptiprivate.h is needed because
it was being bootlegged via xpt_xdr.h. Some of the data structures in
reflect/xptinfo/ (which wrap the xpt_struct.h data structures) are
still allocated using XPTArena. Hopefully we can get rid of that in
followup work.
I also deleted a lot of comments in xpt_struct.h that talk about the
on-disk format. I also deleted checking of the major version number,
because that should not matter when the XPT information is baked into
the executable.
MozReview-Commit-ID: 6NJdaCWRBhU
--HG--
extra : rebase_source : e169b827a64bad5dde15de6be0b2ff5e7aa35e3f
This is similar to the solution adopted for bug 1190985, a race in
netwerk's DebugMutexAutoLock. A relaxed atomic tells tools like TSan
that we're OK with this variable being touched from multiple threads.
That it's only set from within a locked mutex should ensure whatever
memory barriers we need are executed so all threads have a consistent
view of what value it contains.
Getting rid of another |volatile| usage in the codebase is just a bonus.
After this change, we have ShallowSizeOf{In,Ex}cludingThis(), which don't do
anything to measure children. (They can be combined with iteration to measure
children.)
--HG--
extra : rebase_source : f98420176f50990bbc5a25e35788328154cfeb00
Kris Maglione
Coroiu Cristina
Csoregi Natalia
Sylvestre Ledru
arthur.iakab
Andrew McCreight
Dorel Luca
Cosmin Sabou
Brindusan Cristian
Brian Hackett
Mike Hommey
Eric Rahm
Benjamin Smedberg
Iris Hsiao
Alexandre Lissy
Wes Kocher
Nicholas Nethercote
Nathan Froyd
Randall Barker