gecko-dev/xpcom/ds/nsGkAtoms.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

184 lines
6.8 KiB
C
Raw Normal View History

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 11:12:37 +00:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef nsGkAtoms_h___
#define nsGkAtoms_h___
Bug 1411469 - Statically allocate static atoms. r=froydnj 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
2018-03-08 01:59:11 +00:00
#include "nsAtom.h"
// Static atoms are structured carefully to satisfy a lot of constraints.
//
// - We have ~2300 static atoms.
//
// - We want them to be constexpr so they end up in .rodata, and thus shared
// between processes, minimizing memory usage.
//
// - We need them to be in an array, so we can iterate over them (for
// registration and lookups).
//
// - Each static atom has a string literal associated with it. We can't use a
// pointer to the string literal because then the atoms won't end up in
// .rodata. Therefore the string literals and the atoms must be arranged in a
// way such that a numeric index can be used instead. This numeric index
// (nsStaticAtom::mStringOffset) must be computable at compile-time to keep
// the static atom constexpr. It should also not be too large (a uint32_t is
// reasonable).
//
// - Each static atom stores the hash value of its associated string literal;
// it's used in various ways. The hash value must be specified at
// compile-time, to keep the static atom constexpr.
//
// - As well as accessing each static atom via array indexing, we need an
// individual pointer, e.g. nsGkAtoms::foo. We want this to be constexpr so
// it doesn't take up any space in memory.
//
// - The array of static atoms can't be in a .h file, because it's a huge
// constexpr expression, which would blow out compile times. But the
// individual pointers for the static atoms must be in a .h file so they are
// public.
//
// nsGkAtoms below defines static atoms in a way that satisfies these
// constraints. It uses nsGkAtomList.h, which defines the names and values of
// the atoms. nsGkAtomList.h is generated by StaticAtoms.py and has entries
// that look like this:
//
// GK_ATOM(a, "a", 0x01234567, nsStaticAtom, Atom)
// GK_ATOM(bb, "bb", 0x12345678, nsCSSPseudoElementStaticAtom,
// PseudoElementAtom)
// GK_ATOM(Ccc, "Ccc", 0x23456789, nsCSSAnonBoxPseudoStaticAtom,
// InheritingAnonBoxAtom)
//
// Comments throughout this file and nsGkAtoms.cpp show how these entries get
// expanded by macros.
// Trivial subclasses of nsStaticAtom so that function signatures can require
// an atom from a specific atom list.
#define DEFINE_STATIC_ATOM_SUBCLASS(name_) \
class name_ : public nsStaticAtom { \
public: \
constexpr name_(uint32_t aLength, uint32_t aHash, uint32_t aOffset, \
bool aIsAsciiLowercase) \
: nsStaticAtom(aLength, aHash, aOffset, aIsAsciiLowercase) {} \
};
DEFINE_STATIC_ATOM_SUBCLASS(nsCSSAnonBoxPseudoStaticAtom)
DEFINE_STATIC_ATOM_SUBCLASS(nsCSSPseudoElementStaticAtom)
#undef DEFINE_STATIC_ATOM_SUBCLASS
Bug 1411469 - Statically allocate static atoms. r=froydnj 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
2018-03-08 01:59:11 +00:00
namespace mozilla {
namespace detail {
// This `detail` class contains the atom strings and the atom objects. Because
// they are together in a class, the `mStringOffset` field of the atoms will be
// small and can be initialized at compile time.
//
// A `detail` namespace is used because the things within it aren't directly
// referenced by external users of these static atoms.
Bug 1411469 - Statically allocate static atoms. r=froydnj 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
2018-03-08 01:59:11 +00:00
struct GkAtoms {
// The declaration of each atom's string.
//
// Expansion of the example GK_ATOM entries from above:
//
// const char16_t a_string[sizeof("a")];
// const char16_t bb_string[sizeof("bb")];
// const char16_t Ccc_string[sizeof("Ccc")];
//
#define GK_ATOM(name_, value_, hash_, is_ascii_lower_, type_, atom_type_) \
const char16_t name_##_string[sizeof(value_)];
Bug 1411469 - Statically allocate static atoms. r=froydnj 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
2018-03-08 01:59:11 +00:00
#include "nsGkAtomList.h"
#undef GK_ATOM
// The enum value for each atom.
Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU --HG-- extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
2018-03-29 00:48:18 +00:00
enum class Atoms {
// Expansion of the example GK_ATOM entries above:
//
// a,
// bb,
// Ccc,
//
#define GK_ATOM(name_, value_, hash_, is_ascii_lower_, type_, atom_type_) name_,
Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU --HG-- extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
2018-03-29 00:48:18 +00:00
#include "nsGkAtomList.h"
#undef GK_ATOM
AtomsCount
};
const nsStaticAtom mAtoms[static_cast<size_t>(Atoms::AtomsCount)];
Bug 1411469 - Statically allocate static atoms. r=froydnj 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
2018-03-08 01:59:11 +00:00
};
// The offset from the start of the GkAtoms object to the start of the
// nsStaticAtom array inside it. This is used in Rust to avoid problems
// with lld-link.exe on Windows when rust-bindgen generates a non-opaque
// version of GkAtoms.
//
// https://bugzilla.mozilla.org/show_bug.cgi?id=1517685
const ptrdiff_t kGkAtomsArrayOffset = offsetof(GkAtoms, mAtoms);
// The GkAtoms instance is `extern const` so it can be defined in a .cpp file.
//
// XXX: The NS_EXTERNAL_VIS is necessary to work around an apparent GCC bug:
// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87494
#if defined(__GNUC__) && !defined(__clang__)
extern NS_EXTERNAL_VIS const GkAtoms gGkAtoms;
#else
extern const GkAtoms gGkAtoms;
#endif
Bug 1411469 - Statically allocate static atoms. r=froydnj 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
2018-03-08 01:59:11 +00:00
} // namespace detail
} // namespace mozilla
// This class holds the pointers to the individual atoms.
class nsGkAtoms {
Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU --HG-- extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
2018-03-29 00:48:18 +00:00
private:
friend void NS_InitAtomTable();
// This is a useful handle to the array of atoms, used below and also
// possibly by Rust code.
Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU --HG-- extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
2018-03-29 00:48:18 +00:00
static const nsStaticAtom* const sAtoms;
// The number of atoms, used below.
Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU --HG-- extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
2018-03-29 00:48:18 +00:00
static constexpr size_t sAtomsLen =
static_cast<size_t>(mozilla::detail::GkAtoms::Atoms::AtomsCount);
Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU --HG-- extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
2018-03-29 00:48:18 +00:00
public:
static nsStaticAtom* GetAtomByIndex(size_t aIndex) {
MOZ_ASSERT(aIndex < sAtomsLen);
return const_cast<nsStaticAtom*>(&sAtoms[aIndex]);
}
// The definition of the pointer to each static atom.
//
// These types are not `static constexpr <type>* const` -- even though these
// atoms are immutable -- because they are often passed to functions with
// `nsAtom*` parameters that can be passed both dynamic and static atoms.
//
// Expansion of the example GK_ATOM entries above:
//
// static constexpr nsStaticAtom* a =
// const_cast<nsStaticAtom*>(
// &mozilla::detail::gGkAtoms.mAtoms[
// static_cast<size_t>(mozilla::detail::GkAtoms::Atoms::a)]);
//
// static constexpr nsStaticAtom* bb =
// const_cast<nsStaticAtom*>(
// &mozilla::detail::gGkAtoms.mAtoms[
// static_cast<size_t>(mozilla::detail::GkAtoms::Atoms::bb)]);
//
// static constexpr nsStaticAtom* Ccc =
// const_cast<nsStaticAtom*>(
// &mozilla::detail::gGkAtoms.mAtoms[
// static_cast<size_t>(mozilla::detail::GkAtoms::Atoms::Ccc)]);
//
#define GK_ATOM(name_, value_, hash_, is_ascii_lower_, type_, atom_type_) \
static constexpr nsStaticAtom* name_ = const_cast<nsStaticAtom*>( \
&mozilla::detail::gGkAtoms.mAtoms[static_cast<size_t>( \
mozilla::detail::GkAtoms::Atoms::name_)]);
#include "nsGkAtomList.h"
#undef GK_ATOM
};
#endif /* nsGkAtoms_h___ */