To allow XPT information to be shared between processes, it needs to
not contain any pointers, because they cause relocations. I've
eliminated pointers by hoisting all of the variable length data
structures to XPTHeader, into a single array for each type of
data. These data structures now use an index into these arrays to find
their first element. Strings are similar, but they are mashed into a
single giant string, including embedded null terminators. Modifying
the accessor methods to support this is easy, because there is only a
single global instance of each of these arrays in XPTHeader.
MozReview-Commit-ID: 5rgwaEBvDYl
--HG--
extra : rebase_source : 6c35fd1034b727443bb87dfde0a4af4799ed480a
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 6f7d4fd1d6cdea2c14866705a2dc972eb5f43382
Now that there is only one XPTHeader, we can devolve the fields in it
to avoid some indirection. The biggest part here is getting rid of the
mHeader field on xptiTypelibGuts.
The array is [] instead of * to avoid a relocation, by ensuring that
XPTHeader::kInterfaceDirectory as well as the data it points to cannot
be changed.
MozReview-Commit-ID: AzvNTNZKkfi
--HG--
extra : rebase_source : 7b2043cecee5e8d063ea4d0b4a2223b2261c62e7
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 lets us hide later changes to how these arrays are stored. There
should be no behavioral change. Some methods in xpt_struct.h are
declared inline at the end of the header due to the order that classes
are declared in the header.
MozReview-Commit-ID: KAxUKn3sDOD
--HG--
extra : rebase_source : 782fddc7bbf29c8ec73a0c6dbcca0621739e6c6e
This will allow us to work with direct pointers to static atoms that are
initialized at compile-time, rather than pointers to pointers to static atoms
that are initialized at runtime.
MozReview-Commit-ID: K04pEicuqu3
--HG--
extra : rebase_source : c5d895b34567c621f4591769390fc95a4c6ff405
On Windows there are some duplicate keys in nsDirectoryService:
- NS_WIN_STARTUP_DIR is "Strt", and maps to Win_Startup.
- NS_WIN_STARTMENU_DIR is also "Strt", and is meant to map to Win_Startmenu,
but actually maps to Win_Startup because of the key duplication.
- NS_WIN_COMMON_STARTMENU_DIR is "CmStrt", and maps to Win_Common_Startmenu.
- NS_WIN_COMMON_STARTUP_DIR is also "CmStrt", and is meant to map to
Win_Common_Startup, but actually maps to Win_Common_Startmenu because of
the key duplication.
Given the bugginess, it's unsurprising that they aren't used.
This patch removes them. This gets rid of two duplicate static atoms, helping
with bug 1445113.
MozReview-Commit-ID: 9Yx6M0VUaH4
--HG--
extra : rebase_source : 887cb2f2b907a6f3a7b796b6032b385291862323
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
The last piece of code that was using these attributes was removed in
https://hg.mozilla.org/mozilla-central/rev/35b7fa5ebd58
MozReview-Commit-ID: FyF7kzlpqMz
--HG--
extra : rebase_source : edaf64a4be92be1f72ff67f90c03eed09173cce3
Currently static atoms are stored on the heap, but their char buffers are
stored in read-only static memory.
This patch changes the representation of nsStaticAtom (thus making it a
non-trivial subclass of nsAtom). Instead of a pointer to the string, it now has
an mStringOffset field which is a 32-bit offset to the string. (This requires
placement of the string and the atom within the same object so that the offset
is known to be small. The docs and macros in nsStaticAtom.h handle that.)
Static and dynamic atoms now store their chars in different ways: nsStaticAtom
stores them inline, nsDynamicAtom has a pointer to separate storage. So
`mString` and GetStringBuffer() move from nsAtom to nsDynamicAtom.
The change to static atoms means they can be made constexpr and stored in
read-only memory instead of on the heap. On 64-bit this reduces the per-process
overhead by 16 bytes; on 32-bit the saving is 12 bytes. (Further reductions
will be possible in follow-up patches.)
The increased use of constexpr required multiple workarounds for MSVC.
- Multiple uses of MOZ_{PUSH,POP}_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING to
disable warnings about (well-defined!) overflow of unsigned integer
arithmetic.
- The use of -Zc:externConstexpr on all files defining static atoms, to make
MSVC follow the C++ standard(!) and let constexpr variables have external
linkage.
- The use of -constexpr:steps300000 to increase the number of operations
allowed in a constexpr value, in order to handle gGkAtoms, which requires
hashing ~2,500 atom strings.
The patch also changes how HTML5 atoms are handled. They are now treated as
dynamic atoms, i.e. we have "dynamic normal" atoms and "dynamic HTML5 atoms",
and "dynamic atoms" covers both cases, and both are represented via
nsDynamicAtom. The main difference between the two kinds is that dynamic HTML5
atoms still aren't allowed to be used in various operations, most notably
AddRef()/Release(). All this also required moving nsDynamicAtom into the header
file.
There is a slight performance cost to all these changes: now that nsStaticAtom
and nsDynamicAtom store their chars in different ways, a conditional branch is
required in the following functions: Equals(), GetUTF16String(),
WeakAtom::as_slice().
Finally, in about:memory the "explicit/atoms/static/atom-objects" value is no
longer needed, because that memory is static instead of heap-allocated.
MozReview-Commit-ID: 4AxPv05ngZy
We only use nsINamed on runnables for certain kinds of telemetry, and
those kinds of telemetry aren't being gathered on RELEASE_OR_BETA
builds. We effectively make nsINamed::GetName a no-op when we're not
collecting said telemetry. But implementing nsINamed does have a cost:
the vtable of every runnable (and we have hundreds of subclasses of
mozilla::Runnable) will contain pointers for GetName (and extra pointers
for QueryInterface/AddRef/Release), and all those pointers times all
those subclasses adds up quickly. Let's not implement nsINamed when
nsINamed isn't going to be used.
This change saves ~100K of binary size on x86-64 Linux; the savings
should be similar on other 64-bit systems, and ~50K on 32-bit systems.
nsGkAtoms::Home and nsDirectoryAtoms::sOS_HomeDirectory are duplicate static
atoms. This patch comments out the latter to remove the duplication.
MozReview-Commit-ID: LGkjZn0zaoz
MOZ_LOG=modules:4,raw now outputs the log without prefixes with the thread name
and date and stuff, just the exact string that was specified.
MozReview-Commit-ID: HACT5EM4BFm
--HG--
extra : rebase_source : 93590ee405f013791ad63565be6e6d83cad3567f
extra : source : d79d7130b28275c8eb2a475bdc685a345b070888
These functions no longer perform any refcounting, so the existing names are
misleading.
MozReview-Commit-ID: LX55e0bUP8N
--HG--
extra : rebase_source : 89a3da577325286c1d31723acfd4153754f49703
This function captures a common usage pattern, generalizing the existing
IsMember() function.
MozReview-Commit-ID: 5Pt7kqyGD6Y
--HG--
extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
It seems silly to have a tiny utils class with a single function in its own
module. This patch moves it into nsStaticAtom.h/nsAtomTable.cpp. It also
renames nsAtomListUtils as nsStaticAtomUtils. Finally, it uses templates to
remove the need for the `aCount` parameter at callsites.
MozReview-Commit-ID: DvJVoZFv89c
--HG--
extra : rebase_source : 1f1dd27d56e46c71c30c10102ac6132a721e23d1
For bug 1438688, I need to statically initialize all of the data types
in xpt_struct.h. It turns out that the approach I was using for unions
is C99 and not C++. While for some reason Clang and GCC are okay with
that, MSVC is not.
One of the unions is a gnarly anonymous union in
XPTTypeDescriptor. However, every arm of this union is either 1 or 2
uint8_t, so I think it is reasonable to eliminate the union and
replace it with two fields, mData1 and mData2. I've fixed up the
places that read this data to use accessor methods with nice asserts
about the tag on the variant, so if anything I think that part is
nicer.
The code in xpt_struct.cpp that writes to this data is maybe less
nice, but I'm deleting it in bug 1438688 so I think that's okay. We
also lose some detail in the comments about the relationship between
what is stored in memory compared to what is stored on disk, but I
think that's okay, too.
MozReview-Commit-ID: DGi19f8HnMi
--HG--
extra : rebase_source : e3535ecb3d7f02bdb643df153e8aba3e106d9104
We risk a shutdown hang without any clues if a dangling reference somewhere
keeps a SharedThreadPool alive past xpcom-shutdown-threads. This because
xpcom-shutdown-threads waits for all SharedThreadPool to be destroyed before
advancing shutdown further. nsCycleCollector::Shutdown comes after
xpcom-shutdown-threads so it is possible that a reference-cycle unexpectedly
keeps a SharedThreadPool alive and blocks shutdown indefinitely.
This patch attempts to help diagnose future cases like this by printing which
SharedThreadPools we are going to wait for to stderr.
MozReview-Commit-ID: CwTApYUMikA
--HG--
extra : rebase_source : f29d04508cf492c82d65f324d7b1990849a0da13
Most of the classes in xpt.py define a helper method to encode the
values of the flags into a byte, but for some reason Method does
not. It'll be useful to have one for Method for the C++ backend I am
working on.
MozReview-Commit-ID: ESi1CnstbN2
--HG--
extra : rebase_source : 23822e7770e9a3d1b5a2359ae9753f950af3a121
Most of the noise is from the fact that clang-format on parser/html/*.{h,cpp}
reformatted all sorts of stuff. Not running it caused lots of format changes
from the generator... I guess we changed the format rules since the last time
this got run?
MozReview-Commit-ID: IA2G87zUIKN
clang-tidy is complaining about an extra else in
NS_INTERFACE_MAP_ENTRIES_CYCLE_COLLECTION. Not hurting anything, but
could be cleaned up anyways.
MozReview-Commit-ID: 36Lkdhs3fyN
--HG--
extra : rebase_source : 74088c9c2668f43d55133be240d4591880b60dab
Now that nsGkAtoms is in xpcom/, we can call nsGkAtoms::AddRefAtoms() from
NS_InitAtomTable(), which removes the need for DefaultAtoms, and also removes a
duplicate static atom.
MozReview-Commit-ID: CyfvnvZomzZ
--HG--
extra : rebase_source : 53ead62323a340038c1b4594b1a3eb225aa19626
This list of atoms isn't particularly DOM-ish, and having it in xpcom/ will
help with the next patch.
MozReview-Commit-ID: 1Y3Fhn9lNbh
--HG--
rename : dom/base/nsGkAtomList.h => xpcom/ds/nsGkAtomList.h
rename : dom/base/nsGkAtoms.cpp => xpcom/ds/nsGkAtoms.cpp
rename : dom/base/nsGkAtoms.h => xpcom/ds/nsGkAtoms.h
extra : rebase_source : 0a0f6ab4432e0d58ea4662299b750a8c52325ad5
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate
to track runnables execution and dispatch counts.
MozReview-Commit-ID: 51DLj6ORD2O
--HG--
extra : rebase_source : b481c9aa3b735569722bb7472872ec2d22adcb89
Also, I set some flags in the ctor instead of later and I also removed
a comment which refers to SetHeader(), which does not exist any more.
MozReview-Commit-ID: 27mcRTnanrZ
--HG--
extra : rebase_source : ec87aed9fa46c2202b607cbcdb4c8347eaa50949
There are ways for Create() to return access denied for files which already
exist, particularly in the case of locked files. When it does, createUnique()
should check whether the file exists before considering the attempt a failure.
MozReview-Commit-ID: FyJTghk04jH
--HG--
extra : rebase_source : 10e6f2cb7da18e8e6d410b52a593b7455f0d76fa
Because (a) that name better indicates that it's a pointer to a pointer, and
(b) because nsStaticAtom::mString is going to be renamed as mAtom in bug
1411469.
MozReview-Commit-ID: D5tuNOstMgr
--HG--
extra : rebase_source : 9344eeea0288c8c52c069ce21e8bc55f6e0f3f6f
By removing the "Atom" suffix, which is redundant.
MozReview-Commit-ID: 4MCX9Icfjrw
--HG--
extra : rebase_source : c3c759a508a8938b59d36dbb20448d2964b98c91
This undoes the parts of bug 977026 related to manifest parsing that
are still around.
MozReview-Commit-ID: CimJNEl8KKk
--HG--
extra : rebase_source : 7e84ff5e5a4adda66ff35044b7a873d7137e3417
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
A lot of our thread pools use the default stack size for the platform
they're on, which can be rather large (8MB, usually, on Linux and OS X)
and is probably too much for the typical thread in the thread pool
regardless. SharedThreadPool already has some logic for selecting a
reasonable stack size for worker threads; let's move that logic to
nsIThreadManager so that logic (and constant) can be shared more
broadly. (That we already have a couple of instances of
SharedThreadPool usage solely for this constant suggests that it is a
concept that should be available in a more central location.)
The trick here is that we read in the element type before we expand the array, so that we
can write it to the new array before it becomes constified.
MozReview-Commit-ID: 2pbpNVZ3gPZ
--HG--
extra : rebase_source : 4c07fff32ea6b1d5c60ae3e40fb869b737cab13e
Also, change some reinterpret casts to static casts, because there was
no need for them to be reinterpret.
MozReview-Commit-ID: EtPmwxboaq9
--HG--
extra : rebase_source : 59fe2d74c8567af4d8000cb230e8dc0f8bf728ff
Once the XPT data is statically allocated, all of the pointers in
xpt_struct.h have to be made const, as well as the XPTHeader
itself. The existing consumers mostly assume things are const already,
so the bulk of the work is tweaking the deserialization code in
xpt_struct.cpp so that the final result is const. I've broken up these
changes into a set of patches.
This patch also gets rid of xptiTypelibGuts::GetHeader(), which is
never called.
MozReview-Commit-ID: FJpmNjY87SN
--HG--
extra : rebase_source : b28456625e4c80023bd350c67163085011bc7cee
A lot of time is spent during the final big XPT link determining what
the index is for each interface. Changing this to use a map
eliminates about 2/3 of the running time. This patch reduces the run
time to a little under a second on my local OSX machine.
MozReview-Commit-ID: CH4OYXtT19q
--HG--
extra : rebase_source : 6d6f755c57dcbf20112768583948f851b8bf34bf
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 596f590443f727d1a79582202eed122f79ae85cf
The patch also uses GetStringBuffer() in a couple of appropriate places.
MozReview-Commit-ID: JufCUgmO8JL
--HG--
extra : rebase_source : ecd3f17b5560b19622c86759d605fa122d70e48a
The refcount is only used for dynamic atoms.
On 64-bit, this reduces sizeof(nsStaticAtom) from 24 bytes to 16 bytes, and the
on-heap size from 32 bytes to 16 bytes. This saves 42 KiB per process.
On 32-bit, this reduces sizeof(nsStaticAtom) from 16 bytes to 12 bytes, but the
on-heap size stays at 16 bytes, so memory usage is unchanged.
MozReview-Commit-ID: 7d9H7MRHN9a
--HG--
extra : rebase_source : d3eafb3aaf44a592afd6c89cd0519d043056e65a
Andrew McCreight
Masatoshi Kimura
Nicholas Nethercote
Andrew Osmond
Jeff Walden
shindli
Margareta Eliza Balazs
Henri Sivonen
Matt Brubeck
Markus Stange
Coroiu Cristina
Ryan VanderMeulen
L. David Baron
Steve Fink
Gurzau Raul
Nathan Froyd
Narcis Beleuzu
Noemi Erli
Petr Sumbera
Timothy Guan-tin Chien
Boris Zbarsky
arthur.iakab
Miko Mynttinen
Paul Adenot
Kris Maglione
Peter Van der Beken
David Keeler
Emilio Cobos Álvarez
Andreea Pavel
Andreas Pehrson
Samuel Thibault
Bogdan Tara
Adrian Wielgosik
Dorel Luca
Gijs Kruitbosch
Sebastian Hengst
Kyle Machulis
Jan-Ivar Bruaroey
Tarek Ziadé
David Major
ffxbld
Andrea Marchesini
Bas Schouten
Cosmin Sabou
Jim Chen
Kannan Vijayan
Nika Layzell
Olli Pettay