mozilla
/
gecko-dev
зеркало из https://github.com/mozilla/gecko-dev.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
gecko-dev/xpcom/ds/nsStaticAtom.h

249 строки
8.1 KiB
C
Исходник Обычный вид История

Bug 1151541, part 2 - Fix mode lines in xpcom/. r=froydnj
2015-04-09 20:25:05 +03:00
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
Bug 716478 - update licence to MPL 2.
2012-05-21 15:12:37 +04: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/. */
just relanding this file - not part of build yet - to make relanding bug 195262 easier (its been r=dbaron, sr=darin'ed already)
2003-03-21 23:35:14 +03:00
#ifndef nsStaticAtom_h__
#define nsStaticAtom_h__
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
#include <stdint.h>
Bug 1446865 - Move nsAtomListUtils. r=froydnj 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
2018-03-20 03:44:28 +03:00
#include "nsAtom.h"
Bug 1446865 - Introduce nsStaticAtomUtils::Lookup. r=froydnj This function captures a common usage pattern, generalizing the existing IsMember() function. MozReview-Commit-ID: 5Pt7kqyGD6Y --HG-- extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
2018-03-20 05:01:28 +03:00
#include "mozilla/Maybe.h"
Bug 534136 Part 2: Use 16bit-char buffers inside atoms. r=bz sr=mrbkap
2010-03-08 18:45:00 +03:00
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// The following macros are used to define static atoms, typically in
// conjunction with a .h file that defines the names and values of the atoms.
//
// For example, the .h file might be called MyAtomList.h and look like this:
//
// MY_ATOM(one, "one")
// MY_ATOM(two, "two")
// MY_ATOM(three, "three")
//
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 04:59:11 +03:00
// The code defining the static atoms should look something like this:
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
//
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 04:59:11 +03:00
// ====> MyAtoms.h <====
//
// namespace detail {
//
// struct MyAtoms
// {
// #define MY_ATOM(name_, value_) NS_STATIC_ATOM_DECL_STRING(name_, value_)
// #include "MyAtomList.h"
// #undef MY_ATOM
//
// #define MY_ATOM(name_, value_) NS_STATIC_ATOM_DECL_ATOM(name_)
// #include "MyAtomList.h"
// #undef MY_ATOM
// };
//
// extern const MyAtoms gMyAtoms;
//
// } // namespace detail
//
// class nsMyAtoms
// {
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// public:
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 04:59:11 +03:00
// #define MY_ATOM(name_, value_) NS_STATIC_ATOM_DECL_PTR(name_)
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// #include "MyAtomList.h"
// #undef MY_ATOM
// };
//
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 04:59:11 +03:00
// ====> MyAtoms.cpp <====
//
// MOZ_PUSH_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING
// static constexpr MyAtoms gMyAtoms = {
// #define MY_ATOM(name_, value_) NS_STATIC_ATOM_INIT_STRING(value_)
// #include "MyAtomList.h"
// #undef MY_ATOM
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
//
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 04:59:11 +03:00
// #define MY_ATOM(name_, value_) NS_STATIC_ATOM_INIT_ATOM(MyAtoms, name_, value_)
// #include "MyAtomList.h"
// #undef MY_ATOM
// };
// MOZ_POP_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING
//
// #define MY_ATOM(name_, value_) NS_STATIC_ATOM_DEFN_PTR(nsMyAtoms, name_)
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// #include "MyAtomList.h"
// #undef MY_ATOM
//
// static const nsStaticAtomSetup sMyAtomSetup[] = {
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 04:59:11 +03:00
// #define MY_ATOM(name_, value_) NS_STATIC_ATOM_SETUP(mozilla::detail::gMyAtoms, nsMyAtoms, name_)
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// #include "MyAtomList.h"
// #undef MY_ATOM
// };
//
// The macros expand to the following:
//
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 04:59:11 +03:00
// ====> MyAtoms.h <====
//
// // A `detail` namespace is used because the things within it aren't
// // directly referenced by external users of these static atoms.
// 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.
// struct MyAtoms
// {
// const char16_t one_string[4];
// const char16_t two_string[4];
// const char16_t three_string[6];
//
// const nsStaticAtom one_atom;
// const nsStaticAtom two_atom;
// const nsStaticAtom three_atom;
// };
//
// extern const MyAtoms gMyAtoms;
//
// } // namespace detail
//
// // This class holds the pointers to the individual atoms.
// class nsMyAtoms
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// {
// public:
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
// static nsStaticAtom* one;
// static nsStaticAtom* two;
// static nsStaticAtom* three;
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// };
//
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 04:59:11 +03:00
// ====> MyAtoms.cpp <====
//
// // Need to suppress some MSVC warning weirdness with WrappingMultiply().
// MOZ_PUSH_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING
// // Because this is `constexpr` it ends up in read-only memory where it can
// // be shared between processes.
// extern constexpr MyAtoms gMyAtoms = {
// u"one",
// u"two",
// u"three",
//
// nsStaticAtom(u"one", 3, offsetof(MyAtoms, one_atom) -
// offsetof(MyAtoms, one_string)),
// nsStaticAtom(u"two", 3, offsetof(MyAtoms, two_atom) -
// offsetof(MyAtoms, two_string)),
// nsStaticAtom(u"three", 3, offsetof(MyAtoms, three_atom) -
// offsetof(MyAtoms, three_string)),
// };
// MOZ_POP_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING
//
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
// nsStaticAtom* MyAtoms::one;
// nsStaticAtom* MyAtoms::two;
// nsStaticAtom* MyAtoms::three;
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
//
// static const nsStaticAtomSetup sMyAtomSetup[] = {
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 04:59:11 +03:00
// { &detail::gMyAtoms.one_atom, &nsMyAtoms::one },
// { &detail::gMyAtoms.two_atom, &nsMyAtoms::two },
// { &detail::gMyAtoms.three_atom, &nsMyAtoms::three },
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// };
//
// When RegisterStaticAtoms(sMyAtomSetup) is called it iterates over
// sMyAtomSetup[]. E.g. for the first atom it does roughly the following:
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 04:59:11 +03:00
// - MyAtoms::one = one_atom
// - inserts one_atom into the atom table
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
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 04:59:11 +03:00
// The declaration of the atom's string, which must be within the same `detail`
// class as NS_STATIC_ATOM_DECL_ATOM.
#define NS_STATIC_ATOM_DECL_STRING(name_, value_) \
const char16_t name_##_string[sizeof(value_)];
// The declaration of the static atom itself, which must be within the same
// `detail` class as NS_STATIC_ATOM_DECL_STRING.
#define NS_STATIC_ATOM_DECL_ATOM(name_) \
const nsStaticAtom name_##_atom;
// The declaration of the pointer to the static atom, which must be within
// a class.
#define NS_STATIC_ATOM_DECL_PTR(name_) \
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
static nsStaticAtom* name_;
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
// Like NS_STATIC_ATOM_DECL, but for sub-classes of nsStaticAtom.
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 04:59:11 +03:00
#define NS_STATIC_ATOM_SUBCLASS_DECL_PTR(type_, name_) \
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
static type_* name_;
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 04:59:11 +03:00
// The initialization of the atom's string, which must be within a `constexpr`
// instance of the `detail` class.
#define NS_STATIC_ATOM_INIT_STRING(value_) \
u"" value_,
// The initialization of the static atom itself, which must be within a
// `constexpr` instance of the `detail` class.
//
// Note that |value_| is an 8-bit string, and so |sizeof(value_)| is equal
// to the number of chars (including the terminating '\0'). The |u""| prefix
// converts |value_| to a 16-bit string.
#define NS_STATIC_ATOM_INIT_ATOM(class_, name_, value_) \
nsStaticAtom(u"" value_, \
sizeof(value_) - 1, \
offsetof(class_, name_##_atom) - \
offsetof(class_, name_##_string)),
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// The definition of the pointer to the static atom. Initially null, it is
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
// set by RegisterStaticAtoms() to point to a heap-allocated nsStaticAtom.
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 04:59:11 +03:00
#define NS_STATIC_ATOM_DEFN_PTR(class_, name_) \
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
nsStaticAtom* class_::name_;
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
// Like NS_STATIC_ATOM_DEFN, but for sub-classes of nsStaticAtom.
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 04:59:11 +03:00
#define NS_STATIC_ATOM_SUBCLASS_DEFN_PTR(type_, class_, name_) \
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
type_* class_::name_;
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 04:59:11 +03:00
// The StaticAtomSetup. Used during start-up, and in some cases afterwards.
#define NS_STATIC_ATOM_SETUP(detailObj_, class_, name_) \
{ &detailObj_.name_##_atom, &class_::name_ },
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj. It's a sub-class of nsAtom, useful for cases where you know you are dealing exclusively with static atoms. The nice thing about it is that you can use raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.) MozReview-Commit-ID: 4Q6QHX5h44V --HG-- extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
2017-10-27 02:31:13 +03:00
// Like NS_STATIC_ATOM_SUBCLASS, but for sub-classes of nsStaticAtom.
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 04:59:11 +03:00
#define NS_STATIC_ATOM_SUBCLASS_SETUP(detailObj_, class_, name_) \
{ &detailObj_.name_##_atom, \
reinterpret_cast<nsStaticAtom**>(&class_::name_) },
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// Holds data used to initialize large number of atoms during startup. Use
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 04:59:11 +03:00
// NS_STATIC_ATOM_SETUP to initialize these structs.
Bug 1410294 (part 1) - Rename nsStaticAtom as nsStaticAtomSetup. r=froydnj. Because it's the type we use to set up static atoms at startup, not the static atom itself. The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM, for consistency. MozReview-Commit-ID: 1a0KvhYNNw2 --HG-- extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
2017-10-20 06:04:47 +03:00
struct nsStaticAtomSetup
Bug 1022456 - Convert xpcom/ds/ to Gecko style. r=froydnj
2014-07-09 19:15:21 +04:00
{
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 04:59:11 +03:00
const nsStaticAtom* const mAtom;
Bug 1444031 - Rename nsStaticAtom::mAtom as mAtomp. r=froydnj 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
2018-03-08 03:42:06 +03:00
nsStaticAtom** const mAtomp;
Bug 534136 Part 1: Make atoms keep a pointer to an nsStringBuffer rather than storing the data inline. r=bsmedberg
2010-03-08 18:44:59 +03:00
};
just relanding this file - not part of build yet - to make relanding bug 195262 easier (its been r=dbaron, sr=darin'ed already)
2003-03-21 23:35:14 +03:00
Bug 1410294 (part 3) - Overhaul static atom macros. r=froydnj. There are four things that must be provided for every static atom, two of which have a macro: - the atom pointer declaration (no macro); - the atom pointer definition (no macro); - the atom char buffer (NS_STATIC_ATOM_BUFFER); - the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP). This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros to make them easier to use (e.g. all the '##' concatenation now happens within the macros). One consequence of the change is that all static atoms must be within a class, so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms). The patch also adds a big comment explaining how the macros are used, and what their expansion looks like. This makes it a lot easier to understand how static atoms work. Correspondingly, the patch removes some small comments scattered around the macro use points. MozReview-Commit-ID: wpRyrEOTHE --HG-- extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
2017-10-22 00:50:25 +03:00
// Register an array of static atoms with the atom table.
Bug 579517 - Part 1: Automated conversion of NSPR numeric types to stdint types in Gecko; r=bsmedberg This patch was generated by a script. Here's the source of the script for future reference: function convert() { echo "Converting $1 to $2..." find . ! -wholename "*nsprpub*" \ ! -wholename "*security/nss*" \ ! -wholename "*/.hg*" \ ! -wholename "obj-ff-dbg*" \ ! -name nsXPCOMCID.h \ ! -name prtypes.h \ -type f \ \( -iname "*.cpp" \ -o -iname "*.h" \ -o -iname "*.c" \ -o -iname "*.cc" \ -o -iname "*.idl" \ -o -iname "*.ipdl" \ -o -iname "*.ipdlh" \ -o -iname "*.mm" \) | \ xargs -n 1 sed -i -e "s/\b$1\b/$2/g" } convert PRInt8 int8_t convert PRUint8 uint8_t convert PRInt16 int16_t convert PRUint16 uint16_t convert PRInt32 int32_t convert PRUint32 uint32_t convert PRInt64 int64_t convert PRUint64 uint64_t convert PRIntn int convert PRUintn unsigned convert PRSize size_t convert PROffset32 int32_t convert PROffset64 int64_t convert PRPtrdiff ptrdiff_t convert PRFloat64 double
2012-08-22 19:56:38 +04:00
template<uint32_t N>
Bug 1255343 - Stop returning nsresult from NS_RegisterStaticAtoms; r=ehsan It only ever returns NS_OK, and none of the callers check the result.
2016-03-18 11:03:43 +03:00
void
Bug 1410294 (part 1) - Rename nsStaticAtom as nsStaticAtomSetup. r=froydnj. Because it's the type we use to set up static atoms at startup, not the static atom itself. The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM, for consistency. MozReview-Commit-ID: 1a0KvhYNNw2 --HG-- extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
2017-10-20 06:04:47 +03:00
NS_RegisterStaticAtoms(const nsStaticAtomSetup (&aSetup)[N])
Bug 696242 - Convert NS_RegisterStaticAtoms and nsCSSScanner::ReportUnexpectedParams to take an array-reference rather than a pointer and length, making it impossible to pass a pointer/length that are inconsistent. r=jwalden --HG-- extra : rebase_source : 882b5b4d500b1fa242c0a3cfa3084e4171cbaa9d
2012-03-09 06:22:57 +04:00
{
Bug 1410294 (part 1) - Rename nsStaticAtom as nsStaticAtomSetup. r=froydnj. Because it's the type we use to set up static atoms at startup, not the static atom itself. The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM, for consistency. MozReview-Commit-ID: 1a0KvhYNNw2 --HG-- extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
2017-10-20 06:04:47 +03:00
extern void RegisterStaticAtoms(const nsStaticAtomSetup* aSetup,
uint32_t aCount);
RegisterStaticAtoms(aSetup, N);
Bug 696242 - Convert NS_RegisterStaticAtoms and nsCSSScanner::ReportUnexpectedParams to take an array-reference rather than a pointer and length, making it impossible to pass a pointer/length that are inconsistent. r=jwalden --HG-- extra : rebase_source : 882b5b4d500b1fa242c0a3cfa3084e4171cbaa9d
2012-03-09 06:22:57 +04:00
}
just relanding this file - not part of build yet - to make relanding bug 195262 easier (its been r=dbaron, sr=darin'ed already)
2003-03-21 23:35:14 +03:00
Bug 1446865 - Move nsAtomListUtils. r=froydnj 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
2018-03-20 03:44:28 +03:00
// This class holds basic operations on arrays of static atoms.
class nsStaticAtomUtils {
public:
Bug 1446865 - Introduce nsStaticAtomUtils::Lookup. r=froydnj This function captures a common usage pattern, generalizing the existing IsMember() function. MozReview-Commit-ID: 5Pt7kqyGD6Y --HG-- extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
2018-03-20 05:01:28 +03:00
template<uint32_t N>
static mozilla::Maybe<uint32_t> Lookup(nsAtom *aAtom,
const nsStaticAtomSetup (&aSetup)[N])
{
return Lookup(aAtom, aSetup, N);
}
Bug 1446865 - Move nsAtomListUtils. r=froydnj 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
2018-03-20 03:44:28 +03:00
template<uint32_t N>
static bool IsMember(nsAtom *aAtom, const nsStaticAtomSetup (&aSetup)[N])
{
Bug 1446865 - Introduce nsStaticAtomUtils::Lookup. r=froydnj This function captures a common usage pattern, generalizing the existing IsMember() function. MozReview-Commit-ID: 5Pt7kqyGD6Y --HG-- extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
2018-03-20 05:01:28 +03:00
return Lookup(aAtom, aSetup, N).isSome();
Bug 1446865 - Move nsAtomListUtils. r=froydnj 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
2018-03-20 03:44:28 +03:00
}
private:
Bug 1446865 - Introduce nsStaticAtomUtils::Lookup. r=froydnj This function captures a common usage pattern, generalizing the existing IsMember() function. MozReview-Commit-ID: 5Pt7kqyGD6Y --HG-- extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
2018-03-20 05:01:28 +03:00
static mozilla::Maybe<uint32_t> Lookup(nsAtom* aAtom,
const nsStaticAtomSetup* aSetup,
uint32_t aCount)
Bug 1446865 - Move nsAtomListUtils. r=froydnj 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
2018-03-20 03:44:28 +03:00
{
for (uint32_t i = 0; i < aCount; i++) {
if (aAtom == *(aSetup[i].mAtomp)) {
Bug 1446865 - Introduce nsStaticAtomUtils::Lookup. r=froydnj This function captures a common usage pattern, generalizing the existing IsMember() function. MozReview-Commit-ID: 5Pt7kqyGD6Y --HG-- extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
2018-03-20 05:01:28 +03:00
return mozilla::Some(i);
Bug 1446865 - Move nsAtomListUtils. r=froydnj 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
2018-03-20 03:44:28 +03:00
}
}
Bug 1446865 - Introduce nsStaticAtomUtils::Lookup. r=froydnj This function captures a common usage pattern, generalizing the existing IsMember() function. MozReview-Commit-ID: 5Pt7kqyGD6Y --HG-- extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
2018-03-20 05:01:28 +03:00
return mozilla::Nothing();
Bug 1446865 - Move nsAtomListUtils. r=froydnj 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
2018-03-20 03:44:28 +03:00
}
};
just relanding this file - not part of build yet - to make relanding bug 195262 easier (its been r=dbaron, sr=darin'ed already)
2003-03-21 23:35:14 +03:00
#endif