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