Otherwise, one can do thinkos like:
MakeScopeExit(...);
and the scope exiting function will execute much earlier than the
intended:
auto guard = MakeScopeExit(...);
This patch goes through the XPConnect conversion methods, and adds cases for
T_DOMOBJECT which call the Wrap, Unwrap, and Cleanup methods from the
nsXPTDOMObjectInfo objects created in the last part.
For consistency with normal interface pointers, and because it wasn't too
complex, I also added support for including T_DOMOBJECTs in XPCOM arrays.
Unlike the other lists in xptinfo, this list contains relocations. Each
DOMObject has 3 functions generated for it, `Wrap`, `Unwrap` and `Cleanup`,
which perform the necessary actions. These are stored as function pointers.
Wrap gets the DOMObject wrapper using the DOM binding code, Unwrap gets the
underlying C++ object, and addrefs it (as XPCOM methods return native types
via getter_AddRefs), and Cleanup releases a reference to the underlying
C++ object, for when the unwrapped object is used as a temporary during a call.
To generate the code, we need to have the declaration of the native C++ type
in scope, so we also emit #include-s for the headerFiles.
They are parsed into a WebIDL object, and lowered into C++, Rust, and XPT.
For C++ code, we generate a correctly namespaced forward declaration. In Rust,
the types are exposed as `*const c_void`, as we don't have WebIDL type
information there.
The XPT code generator needs to know the header filename in order to perform
correct codegen, so we also get that information.
Due to the decision to keep the old API on nsXPTInterfaceInfo in part 4, this is
a fairly straightforward patch.
1. I had to change a couple of consumers of `IsRetval()` due to the movement of
that flag.
2. I changed all code which held a nsIInterfaceInfo to hold an `const
nsXPTInterfaceInfo*` instead.
3. I changed code which used the nsIInterfaceInfoManager to instead call the
static methods on nsXPTInterfaceInfo.
This patch contains the meat of the changes here. The following summarize the changes:
1. xptinfo.h is rewritten to expose the new interface for reading the XPT data,
The nsXPTInterfaceInfo object exposes methods with the same signatures as
the methods on nsIInterfaceInfo, to make converting code which used
nsIInterfaceInfo as easy as possible, even when those methods don't have
signatures which make a ton of sense anymore. There are also a few methods
which are unnecessary (they return `true` or similar), which should be
removed over time.
Members of the data structures are made private in order to prevent reading
them directly. Code should instead call the getter methods. This should make
it easier to change their memory representation in the future. Constructing
these structs is made possible by making the structs `friend class` with the
XPTConstruct class, which is implemented by the code generator, and is able
to access the private fields.
In addition, rather than using integers with flag constants, I opted for
using C++ bitfields to store individual flags, as I found it made it easier
to both write the code generator, and reason about the layouts of the types.
I was able to shave a byte off of each nsXPTParamInfo (4 bytes -> 3 bytes)
by shoving the flags into spare bits in the nsXPTType. Unfortunately there
was not enough room for the retval flag. Fortunately, we already depend in
our code on the retval parameter being the last parameter, so I worked
around this by removing the retval flag and instead having a `hasretval`
flag on the method itself.
2. An xptinfo.cpp file is added for out-of-line definitions of more complex
methods, and the internal implementation details of the perfect hash.
Notable is the handling of xptshim interfaces. As the type is uniform, a
flag is checked when trying to read constant information, and a different
table with pointers into webidl data structures is checked when the type is
determined to be a shim.
Ideally we could remove this once we remove the remaining consumers of the
existing shim interfaces.
3. A python code generator which takes in the json XPT files generated in the
previous part, and emits a xptdata.cpp file with the data structures. I did
my best to heavily comment the code.
This code uses the friend class trick to construct the private fields of the
structs, and avoid a dependency on the ordering of fields in xptinfo.h.
The sInterfaces array's order is determined by a generated perfect hash
which is also written into the binary. This should allow for fast lookups by
IID or name of interfaces in memory. The hash function used for the perfect
hash is a simple FNV hash, as they're pretty fast.
For perfect hashing of names, another table is created which contains
indexes into the sInterfaces table. Lookup by name is less common, and this
form of lookup should still be very fast.
4. The necessary Makefiles are updated to use the new code generator, and
generate the file correctly.
This patch adds a python script based on the old typelib.py script which takes
in a parsed XPIDL file, and generates a json-based XPT file to use as a build
intermediate. I did my best to keep the generated format simple.
In the previous patch, one of the files which was deleted is ShimInterfaceInfo.
This is an implementor of nsIInterfaceInfo which exists for legacy reasons, in
order to allow Components.interfaces.nsIDOM* to have the correct constants and
IIDs associated with them.
As that file was deleted, this information now has to be stored in the typelib.
To do this, the information is moved to the xptshim and xptshimfile attributes
on the relevant xpcom interfaces.
xptshim(...) means that this xpcom interface is a shim for the WebIDL interface
with the specified name.
xptshimfile(...) is for use when the webidl interface is declared in another
interface's .webidl file, (in our case, MessageManager.webidl). It contains the
name of the parent binding, such that we can #include the correct file in our
generated code.
This patch does not add the code which uses these changes, only the parsing
logic.
Unfortunately, I wasn't able to figure out a way to make firefox build & run in
the intermediate stages of these commits. Because of this, I am going to just
delete most of the code which I am deleting in the first patch, as I figure that
those are somewhat uninteresting changes, and then make the other changes in the
following patches.
In total, the following things are deleted:
1. All of xpcom/typelib, except for `xpt/tools` - this directory is being
subsumed entirely into xpcom/reflect/xptinfo.
2. Most of the code in xpcom/reflect/xptinfo, it is being rewritten to avoid
allocating and contain all of the necessary data structures.
3. idl-parser's typelib.py XPT generator, as it will be replaced.
4. Most includes of files which have been deleted.
NOTE: xpcom/typelib/xpt/tools/xpt.py was not removed, as it is used by bundling
code & bundling tests, which we don't want to remove yet.
...on Windows, at least. Apparently if you have environment variables
set that contain multibyte characters, and ask for them with getenv, you
get garbage. Or perhaps you get something sensible, but then passing it
to fopen produces garbage. Either way, the most reasonable way to
handle this is to use the Windows wide-character APIs all over.
We need to detect the flatpak environment on multiple places.
Making the ShouldUseFlatpakPortal() exported to the nsIGIOService
allows us to reuse it.
MozReview-Commit-ID: 41NJyR3fqZQ
--HG--
extra : rebase_source : 4ebb9ba2ff98d3c6d924223485e028929eb801ed
c_char isn't i8 on some platforms such as Android/arm, so we should use c_char
instead.
MozReview-Commit-ID: 486BCGvYAE0
--HG--
extra : rebase_source : 0ee9d510de5cd8ab20daa1709c7425ca95dc8793
This removes properties of XULElement that can easily seen to be unused, even if the attributes they control are still in use. There are other properties that may still be used once or twice, and they are not removed here.
MozReview-Commit-ID: IL6mCvtGQAG
--HG--
extra : rebase_source : 4b22b330d311ef22e3466f517c04d5a19512ab71
Many of these fields have accessors, and can only be read indirectly
by going through the XPTHeader data structure anyways, so they should
be marked private. This makes the generated XPT data file noisier due
to the need for constexpr constructors.
I had to fix the ctors for the classes in xptinfo.h to be less weird
because there was a compiler error.
Members in two of the classes need to be marked protected because they
have subclasses in xptinfo.h. Ideally those classes would be merged
in.
MozReview-Commit-ID: 70IdFAhp5je
--HG--
extra : rebase_source : 48cb1ec84c872b8fd6bb8c07f8ad2b47d0173f28
Chromeutils.RequestPerformanceMetrics() is now composed of two parts:
- calls content processes via IPDL to get their counters
- directly dispatch counters from the parent process
MozReview-Commit-ID: HlgcEOzkyAq
--HG--
extra : rebase_source : 60e81a27cd3a1bf1378e6b977529964507633b63
Many of these fields have accessors, and can only be read indirectly
by going through the XPTHeader data structure anyways, so they should
be marked private. This makes the generated XPT data file noisier due
to the need for constexpr constructors.
I had to fix the ctors for the classes in xptinfo.h to be less weird
because there was a compiler error.
Members in two of the classes need to be marked protected because they
have subclasses in xptinfo.h. Ideally those classes would be merged
in.
MozReview-Commit-ID: 70IdFAhp5je
--HG--
extra : rebase_source : a2670a65ace291defc47845c4058477f0ae5360a
The things in xptiWorkingSet are neither used nor defined.
MozReview-Commit-ID: 1ZPVe38OVcH
--HG--
extra : rebase_source : 6f74c70758cb66bfdc6ec0a2a27d8cead1b37ed6
This sets a new baseline for these benchmarks.
MozReview-Commit-ID: 1BotMvQ8Rjg
--HG--
extra : rebase_source : 5dd8f6004dd477ce57f94d5af072859b280d30f8
Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer
to the canonical pointer to that static atom. Which is pretty weird! The
notable thing thing about it is that these structs are in an array, and that
gives us the only way to iterate over all static atoms in a single class, for
registration and lookups.
But thanks to various other recent changes to the implementation of static
atoms, we can now put the static atoms themselves into an array, which can be
iterated over. So this patch does that. With that done, nsStaticAtomSetup is no
longer necessary.
According to the `size` utility, on Linux64 this reduces the size of libxul.so
by the following amounts:
> text: 62008 bytes
> data: 20992 bytes
> bss: 21040 bytes
> total: 104040 bytes
- The bss reduction is one word per atom, because the canonical static atom
pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're
now initialized at compile time instead of runtime.
- The data reduction is one word per atom, because we remove two words per atom
for the nsStaticAtomSetup removal, but gain one word per atom from the
previous bullet point.
- I'm not sure about the text reduction. It's three words per atom. Maybe
because there is one less relocation per atom?
Other notable things in the patch:
- nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom,
not nsAtom, because that's more precise.
- Each static atoms array now has an enum associated with it, which is used in
various ways.
- In the big comment about the macros at the top of nsStaticAtom.h, the pre-
and post-expansion forms are now shown interleaved. The interleaving reduces
duplication and makes the comment much easier to read and maintain. The
comment also has an introduction that explains the constraints and goals of
the implementation.
- The SUBCLASS macro variations are gone. There are few enough users of these
macros now that always passing the atom type has become simpler.
MozReview-Commit-ID: 1GmfKidLjaU
--HG--
extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
For nsCSSAnonBoxes.cpp, nsCSSPseudoElements.cpp, nsDirectoryService.cpp, the
corresponding .h file includes nsStaticAtom.h. For the other files in this
patch, nsStaticAtom.h is not needed at all.
MozReview-Commit-ID: IpMmbXwZHhu
--HG--
extra : rebase_source : 46d0a6b40a41ee233adad7c205cf907fa27de34a
This patch handles the actual generation of the static data structures
used to represent XPT information. XPT files are generated in the same
way as they are now, but they are used only as an intermediate
representation to speed up incremental compilation rather than
something used by Firefox itself. Instead of linking XPTs into a
single big XPT file at packaging time, they are linked into a single
big C++ file at build time, that defines the various static consts in
XPTHeader.
In xpt.py, every data structure that can get written to disk gets an
additional code_gen() method that returns a representation of that
data structure as C++ source code. CodeGenData aggregates this
information together, handling deduplication and the final source code
generation.
The ctors are needed for XPTConstValue to statically initialize the
different union cases without resorting to designated initializers,
which are part of C99, not C++. Designated initializers appear to be
supported in C++ code by Clang and GCC, but not MSVC. The ctors must
be constexpr to ensure they are actually statically initialized so
they can be shared between Firefox processes.
I also removed an unnecessary "union" in XPTConstDescriptor.
Together, these patches reduce the amount of memory reported by
xpti-working-set from about 860,000 bytes to about 200,000 bytes. The
remaining memory is used for xptiInterface and xptiTypelibGuts (which
are thin wrappers around the XPT interfaces and header) and hash
tables to speed up looking up interfaces by name or IID. That could
potentially be eliminated from dynamic allocations in follow up
work. These patches did not affect memory reporting because XPT arenas
are still used by the remaining XPTI data structures.
MozReview-Commit-ID: Jvi9ByCPa6H
--HG--
extra : rebase_source : a9e48e7026aab4ad1b7f97e50424adf4e3f4142f
With fully linked XPT data, there is exactly one directory entry per
descriptor, plus one per unresolved interface. There are 1200 of the
former and 40 of the latter. By merging them, we save a 32 bit int per
directory entry, at the cost of 11 bytes per unresolved interface.
This will make VerifyAndAddEntryIfNew slightly slower because it has
to do an nsID equality check rather than a null check, but I can't
imagine that will matter.
My main goal for this patch is to reduce the size of the executable,
to avoid a regression with my static XPT information patches, but it
should reduce memory a little bit, too.
MozReview-Commit-ID: L35YdOuAyF4
--HG--
extra : rebase_source : 8358a73a0f8f81081661538d4a7c9a31b1aa7a56
To allow XPT information to be shared between processes, it needs to
not contain any pointers, because they cause relocations. I've
eliminated pointers by hoisting all of the variable length data
structures to XPTHeader, into a single array for each type of
data. These data structures now use an index into these arrays to find
their first element. Strings are similar, but they are mashed into a
single giant string, including embedded null terminators. Modifying
the accessor methods to support this is easy, because there is only a
single global instance of each of these arrays in XPTHeader.
MozReview-Commit-ID: 5rgwaEBvDYl
--HG--
extra : rebase_source : 2e423f088d662920a89f3b66c70d26fe340b5fce
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
Now that there is only one XPTHeader, we can devolve the fields in it
to avoid some indirection. The biggest part here is getting rid of the
mHeader field on xptiTypelibGuts.
The array is [] instead of * to avoid a relocation, by ensuring that
XPTHeader::kInterfaceDirectory as well as the data it points to cannot
be changed.
MozReview-Commit-ID: AzvNTNZKkfi
--HG--
extra : rebase_source : d911a54b3db1f9f57b538d13ae86f28965ab33b3
This patch removes C++ code related to reading in XPT information from
files. (Code related to packaging XPT files will be removed in the
next patch.) This includes code in the manifest parser, in addition to
the actual code for parsing files.
XPT information is now loaded directly from a single static data
structure, XPTHeader::kHeader, which will be automatically generated
at compile time from .idl files (via .xpt files). Note that the script
to do that is not added until part 6 of this patch series, so linking
will fail on parts 2 through 5.
I inlined XPTInterfaceInfoManager::RegisterXPTHeader into the ctor,
because that is the only caller. It feels like the lock there should
not be needed any more, but I left it alone for now.
The forward declaration of XPTArena in xptiprivate.h is needed because
it was being bootlegged via xpt_xdr.h. Some of the data structures in
reflect/xptinfo/ (which wrap the xpt_struct.h data structures) are
still allocated using XPTArena. Hopefully we can get rid of that in
followup work.
I also deleted a lot of comments in xpt_struct.h that talk about the
on-disk format. I also deleted checking of the major version number,
because that should not matter when the XPT information is baked into
the executable.
MozReview-Commit-ID: 6NJdaCWRBhU
--HG--
extra : rebase_source : 6512a05f2a8bee1e6e6b0423d2cb376d8c34728b
This lets us hide later changes to how these arrays are stored. There
should be no behavioral change. Some methods in xpt_struct.h are
declared inline at the end of the header due to the order that classes
are declared in the header.
MozReview-Commit-ID: KAxUKn3sDOD
--HG--
extra : rebase_source : 867ce100e5178c85485e6c3bac5d6bfca098f78b
This patch handles the actual generation of the static data structures
used to represent XPT information. XPT files are generated in the same
way as they are now, but they are used only as an intermediate
representation to speed up incremental compilation rather than
something used by Firefox itself. Instead of linking XPTs into a
single big XPT file at packaging time, they are linked into a single
big C++ file at build time, that defines the various static consts in
XPTHeader.
In xpt.py, every data structure that can get written to disk gets an
additional code_gen() method that returns a representation of that
data structure as C++ source code. CodeGenData aggregates this
information together, handling deduplication and the final source code
generation.
The ctors are needed for XPTConstValue to statically initialize the
different union cases without resorting to designated initializers,
which are part of C99, not C++. Designated initializers appear to be
supported in C++ code by Clang and GCC, but not MSVC. The ctors must
be constexpr to ensure they are actually statically initialized so
they can be shared between Firefox processes.
I also removed an unnecessary "union" in XPTConstDescriptor.
Together, these patches reduce the amount of memory reported by
xpti-working-set from about 860,000 bytes to about 200,000 bytes. The
remaining memory is used for xptiInterface and xptiTypelibGuts (which
are thin wrappers around the XPT interfaces and header) and hash
tables to speed up looking up interfaces by name or IID. That could
potentially be eliminated from dynamic allocations in follow up
work. These patches did not affect memory reporting because XPT arenas
are still used by the remaining XPTI data structures.
MozReview-Commit-ID: Jvi9ByCPa6H
--HG--
extra : rebase_source : 719dfbcb9f83235c0f1f0766270b7f127f9ab04e
With fully linked XPT data, there is exactly one directory entry per
descriptor, plus one per unresolved interface. There are 1200 of the
former and 40 of the latter. By merging them, we save a 32 bit int per
directory entry, at the cost of 11 bytes per unresolved interface.
This will make VerifyAndAddEntryIfNew slightly slower because it has
to do an nsID equality check rather than a null check, but I can't
imagine that will matter.
My main goal for this patch is to reduce the size of the executable,
to avoid a regression with my static XPT information patches, but it
should reduce memory a little bit, too.
MozReview-Commit-ID: L35YdOuAyF4
--HG--
extra : rebase_source : b3d0780808f9fc708b5b2dffeda45030974dc0bf
To allow XPT information to be shared between processes, it needs to
not contain any pointers, because they cause relocations. I've
eliminated pointers by hoisting all of the variable length data
structures to XPTHeader, into a single array for each type of
data. These data structures now use an index into these arrays to find
their first element. Strings are similar, but they are mashed into a
single giant string, including embedded null terminators. Modifying
the accessor methods to support this is easy, because there is only a
single global instance of each of these arrays in XPTHeader.
MozReview-Commit-ID: 5rgwaEBvDYl
--HG--
extra : rebase_source : 6c35fd1034b727443bb87dfde0a4af4799ed480a
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 6f7d4fd1d6cdea2c14866705a2dc972eb5f43382
Now that there is only one XPTHeader, we can devolve the fields in it
to avoid some indirection. The biggest part here is getting rid of the
mHeader field on xptiTypelibGuts.
The array is [] instead of * to avoid a relocation, by ensuring that
XPTHeader::kInterfaceDirectory as well as the data it points to cannot
be changed.
MozReview-Commit-ID: AzvNTNZKkfi
--HG--
extra : rebase_source : 7b2043cecee5e8d063ea4d0b4a2223b2261c62e7
This patch removes C++ code related to reading in XPT information from
files. (Code related to packaging XPT files will be removed in the
next patch.) This includes code in the manifest parser, in addition to
the actual code for parsing files.
XPT information is now loaded directly from a single static data
structure, XPTHeader::kHeader, which will be automatically generated
at compile time from .idl files (via .xpt files). Note that the script
to do that is not added until part 6 of this patch series, so linking
will fail on parts 2 through 5.
I inlined XPTInterfaceInfoManager::RegisterXPTHeader into the ctor,
because that is the only caller. It feels like the lock there should
not be needed any more, but I left it alone for now.
The forward declaration of XPTArena in xptiprivate.h is needed because
it was being bootlegged via xpt_xdr.h. Some of the data structures in
reflect/xptinfo/ (which wrap the xpt_struct.h data structures) are
still allocated using XPTArena. Hopefully we can get rid of that in
followup work.
I also deleted a lot of comments in xpt_struct.h that talk about the
on-disk format. I also deleted checking of the major version number,
because that should not matter when the XPT information is baked into
the executable.
MozReview-Commit-ID: 6NJdaCWRBhU
--HG--
extra : rebase_source : e169b827a64bad5dde15de6be0b2ff5e7aa35e3f
This lets us hide later changes to how these arrays are stored. There
should be no behavioral change. Some methods in xpt_struct.h are
declared inline at the end of the header due to the order that classes
are declared in the header.
MozReview-Commit-ID: KAxUKn3sDOD
--HG--
extra : rebase_source : 782fddc7bbf29c8ec73a0c6dbcca0621739e6c6e
This will allow us to work with direct pointers to static atoms that are
initialized at compile-time, rather than pointers to pointers to static atoms
that are initialized at runtime.
MozReview-Commit-ID: K04pEicuqu3
--HG--
extra : rebase_source : c5d895b34567c621f4591769390fc95a4c6ff405
On Windows there are some duplicate keys in nsDirectoryService:
- NS_WIN_STARTUP_DIR is "Strt", and maps to Win_Startup.
- NS_WIN_STARTMENU_DIR is also "Strt", and is meant to map to Win_Startmenu,
but actually maps to Win_Startup because of the key duplication.
- NS_WIN_COMMON_STARTMENU_DIR is "CmStrt", and maps to Win_Common_Startmenu.
- NS_WIN_COMMON_STARTUP_DIR is also "CmStrt", and is meant to map to
Win_Common_Startup, but actually maps to Win_Common_Startmenu because of
the key duplication.
Given the bugginess, it's unsurprising that they aren't used.
This patch removes them. This gets rid of two duplicate static atoms, helping
with bug 1445113.
MozReview-Commit-ID: 9Yx6M0VUaH4
--HG--
extra : rebase_source : 887cb2f2b907a6f3a7b796b6032b385291862323
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
The last piece of code that was using these attributes was removed in
https://hg.mozilla.org/mozilla-central/rev/35b7fa5ebd58
MozReview-Commit-ID: FyF7kzlpqMz
--HG--
extra : rebase_source : edaf64a4be92be1f72ff67f90c03eed09173cce3
Currently static atoms are stored on the heap, but their char buffers are
stored in read-only static memory.
This patch changes the representation of nsStaticAtom (thus making it a
non-trivial subclass of nsAtom). Instead of a pointer to the string, it now has
an mStringOffset field which is a 32-bit offset to the string. (This requires
placement of the string and the atom within the same object so that the offset
is known to be small. The docs and macros in nsStaticAtom.h handle that.)
Static and dynamic atoms now store their chars in different ways: nsStaticAtom
stores them inline, nsDynamicAtom has a pointer to separate storage. So
`mString` and GetStringBuffer() move from nsAtom to nsDynamicAtom.
The change to static atoms means they can be made constexpr and stored in
read-only memory instead of on the heap. On 64-bit this reduces the per-process
overhead by 16 bytes; on 32-bit the saving is 12 bytes. (Further reductions
will be possible in follow-up patches.)
The increased use of constexpr required multiple workarounds for MSVC.
- Multiple uses of MOZ_{PUSH,POP}_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING to
disable warnings about (well-defined!) overflow of unsigned integer
arithmetic.
- The use of -Zc:externConstexpr on all files defining static atoms, to make
MSVC follow the C++ standard(!) and let constexpr variables have external
linkage.
- The use of -constexpr:steps300000 to increase the number of operations
allowed in a constexpr value, in order to handle gGkAtoms, which requires
hashing ~2,500 atom strings.
The patch also changes how HTML5 atoms are handled. They are now treated as
dynamic atoms, i.e. we have "dynamic normal" atoms and "dynamic HTML5 atoms",
and "dynamic atoms" covers both cases, and both are represented via
nsDynamicAtom. The main difference between the two kinds is that dynamic HTML5
atoms still aren't allowed to be used in various operations, most notably
AddRef()/Release(). All this also required moving nsDynamicAtom into the header
file.
There is a slight performance cost to all these changes: now that nsStaticAtom
and nsDynamicAtom store their chars in different ways, a conditional branch is
required in the following functions: Equals(), GetUTF16String(),
WeakAtom::as_slice().
Finally, in about:memory the "explicit/atoms/static/atom-objects" value is no
longer needed, because that memory is static instead of heap-allocated.
MozReview-Commit-ID: 4AxPv05ngZy
We only use nsINamed on runnables for certain kinds of telemetry, and
those kinds of telemetry aren't being gathered on RELEASE_OR_BETA
builds. We effectively make nsINamed::GetName a no-op when we're not
collecting said telemetry. But implementing nsINamed does have a cost:
the vtable of every runnable (and we have hundreds of subclasses of
mozilla::Runnable) will contain pointers for GetName (and extra pointers
for QueryInterface/AddRef/Release), and all those pointers times all
those subclasses adds up quickly. Let's not implement nsINamed when
nsINamed isn't going to be used.
This change saves ~100K of binary size on x86-64 Linux; the savings
should be similar on other 64-bit systems, and ~50K on 32-bit systems.
nsGkAtoms::Home and nsDirectoryAtoms::sOS_HomeDirectory are duplicate static
atoms. This patch comments out the latter to remove the duplication.
MozReview-Commit-ID: LGkjZn0zaoz
MOZ_LOG=modules:4,raw now outputs the log without prefixes with the thread name
and date and stuff, just the exact string that was specified.
MozReview-Commit-ID: HACT5EM4BFm
--HG--
extra : rebase_source : 93590ee405f013791ad63565be6e6d83cad3567f
extra : source : d79d7130b28275c8eb2a475bdc685a345b070888
These functions no longer perform any refcounting, so the existing names are
misleading.
MozReview-Commit-ID: LX55e0bUP8N
--HG--
extra : rebase_source : 89a3da577325286c1d31723acfd4153754f49703
This function captures a common usage pattern, generalizing the existing
IsMember() function.
MozReview-Commit-ID: 5Pt7kqyGD6Y
--HG--
extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
It seems silly to have a tiny utils class with a single function in its own
module. This patch moves it into nsStaticAtom.h/nsAtomTable.cpp. It also
renames nsAtomListUtils as nsStaticAtomUtils. Finally, it uses templates to
remove the need for the `aCount` parameter at callsites.
MozReview-Commit-ID: DvJVoZFv89c
--HG--
extra : rebase_source : 1f1dd27d56e46c71c30c10102ac6132a721e23d1
For bug 1438688, I need to statically initialize all of the data types
in xpt_struct.h. It turns out that the approach I was using for unions
is C99 and not C++. While for some reason Clang and GCC are okay with
that, MSVC is not.
One of the unions is a gnarly anonymous union in
XPTTypeDescriptor. However, every arm of this union is either 1 or 2
uint8_t, so I think it is reasonable to eliminate the union and
replace it with two fields, mData1 and mData2. I've fixed up the
places that read this data to use accessor methods with nice asserts
about the tag on the variant, so if anything I think that part is
nicer.
The code in xpt_struct.cpp that writes to this data is maybe less
nice, but I'm deleting it in bug 1438688 so I think that's okay. We
also lose some detail in the comments about the relationship between
what is stored in memory compared to what is stored on disk, but I
think that's okay, too.
MozReview-Commit-ID: DGi19f8HnMi
--HG--
extra : rebase_source : e3535ecb3d7f02bdb643df153e8aba3e106d9104
We risk a shutdown hang without any clues if a dangling reference somewhere
keeps a SharedThreadPool alive past xpcom-shutdown-threads. This because
xpcom-shutdown-threads waits for all SharedThreadPool to be destroyed before
advancing shutdown further. nsCycleCollector::Shutdown comes after
xpcom-shutdown-threads so it is possible that a reference-cycle unexpectedly
keeps a SharedThreadPool alive and blocks shutdown indefinitely.
This patch attempts to help diagnose future cases like this by printing which
SharedThreadPools we are going to wait for to stderr.
MozReview-Commit-ID: CwTApYUMikA
--HG--
extra : rebase_source : f29d04508cf492c82d65f324d7b1990849a0da13
Nathan Froyd
Nika Layzell
Csoregi Natalia
Nicholas Nethercote
Jan Horak
Makoto Kato
Margareta Eliza Balazs
Gijs Kruitbosch
Jeff Walden
Noemi Erli
Jan de Mooij
Andreea Pavel
Tom Bannister
Sebastian Hengst
Eric Rahm
Sylvestre Ledru
Karl Tomlinson
Honza Bambas
Andrea Marchesini
Tristan Bourvon
Jim Blandy
arthur.iakab
Coroiu Cristina
Andrew McCreight
Venkatesh Pitta
Stephen A Pohl
Boris Zbarsky
Brindusan Cristian
Bobby Holley
Paolo Amadini
Henri Sivonen
Narcis Beleuzu
Tarek Ziadé
Honza Bambas
Dorel Luca
Masatoshi Kimura
Andrew Osmond
shindli
Matt Brubeck
Markus Stange
Ryan VanderMeulen
L. David Baron
Steve Fink
Gurzau Raul
Petr Sumbera
Timothy Guan-tin Chien
Miko Mynttinen
Paul Adenot
Kris Maglione
Peter Van der Beken
David Keeler
Emilio Cobos Álvarez
Andreas Pehrson
Samuel Thibault
Bogdan Tara
Adrian Wielgosik