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
