2c4b2de24d06b4547db6b0305be3263392137551: Bug 1449838 part 2: Morph 'usingFlexBasisForISize' variable in nsFrame::ComputeSize* methods, to better reflect reality. r?mats draft
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Mar 2018 22:11:48 -0700 - rev 774598
Push 104440 by dholbert@mozilla.com at Thu, 29 Mar 2018 05:12:31 +0000
Bug 1449838 part 2: Morph 'usingFlexBasisForISize' variable in nsFrame::ComputeSize* methods, to better reflect reality. r?mats This patch doesn't affect behavior; it just adjusts a variable for clarity. Really, this variable tracks which axis (inline vs. block) is the main axis (if we're a flex item). So, this patch morphs the variable to more directly track that. The variable's old name 'usingFlexBasisForISize' was confusing, because even when it was set to 'true', we might not *really* be using the flex-basis in place of the ISize property. In particular: when we have 'flex-basis:auto', we don't use 'flex-basis' in place of the ISize/BSize property -- rather, that indicates that 'flex-basis' is *deferring* to the main-axis size property. Hopefully the new name/type makes it clearer what we're actually tracking. MozReview-Commit-ID: CEqBfjm04XA
198155caaaf551b67257c45800ba9f8a315ede88: Bug 1449838 part 1: Add utility function nsFlexContainerFrame::IsItemInlineAxisMainAxis(). r?mats draft
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Mar 2018 22:11:17 -0700 - rev 774597
Push 104440 by dholbert@mozilla.com at Thu, 29 Mar 2018 05:12:31 +0000
Bug 1449838 part 1: Add utility function nsFlexContainerFrame::IsItemInlineAxisMainAxis(). r?mats This patch doesn't affect behavior - it's just refactoring / de-duplicating. MozReview-Commit-ID: EE7WV0kD9SK
a7ee922fb4b6f7e167f032dd4c52086c551ee462: Bug 1449838 part 2: Morph 'usingFlexBasisForISize' variable in nsFrame::ComputeSize* methods, to better reflect reality. r?mats draft
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Mar 2018 21:58:37 -0700 - rev 774596
Push 104439 by dholbert@mozilla.com at Thu, 29 Mar 2018 04:59:32 +0000
Bug 1449838 part 2: Morph 'usingFlexBasisForISize' variable in nsFrame::ComputeSize* methods, to better reflect reality. r?mats This patch doesn't affect behavior; it just adjusts a variable for clarity. Really, this variable tracks which axis (inline vs. block) is the main axis (if we're a flex item). So, this patch morphs the variable to more directly track that. The variable's old name 'usingFlexBasisForISize' was confusing, because even when it was set to 'true', we might not *really* be using the flex-basis in place of the ISize property. In particular: when we have 'flex-basis:auto', we don't use 'flex-basis' in place of the ISize/BSize property -- rather, that indicates that 'flex-basis' is *deferring* to the main-axis size property. Hopefully the new name/type makes it clearer what we're actually tracking. MozReview-Commit-ID: ILvhJROS3yO
c648e4fc5f42727fbf96cc62fe5e788ed7432c22: Bug 1449838 part 1: Add utility function nsFlexContainerFrame::IsItemInlineAxisMainAxis(). r?mats draft
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Mar 2018 21:58:06 -0700 - rev 774595
Push 104439 by dholbert@mozilla.com at Thu, 29 Mar 2018 04:59:32 +0000
Bug 1449838 part 1: Add utility function nsFlexContainerFrame::IsItemInlineAxisMainAxis(). r?mats This patch doesn't affect behavior - it's just refactoring / de-duplicating. MozReview-Commit-ID: Eu0acUw7V6J
929148ddce5523741066edc7d2223bc2037db0b7: Bug 1436881: Remove redundant special-case code for treating flex-basis enum values as 'auto' in vertical axis. r?mats draft
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 28 Mar 2018 21:28:18 -0700 - rev 774594
Push 104439 by dholbert@mozilla.com at Thu, 29 Mar 2018 04:59:32 +0000
Bug 1436881: Remove redundant special-case code for treating flex-basis enum values as 'auto' in vertical axis. r?mats This patch should not affect behavior. Logic-wise: the idea behind this patch is to behave as if the 'usingFlexBasisForHeight' variable were always false, which in turn lets us remove an "if (!usingFlexBasisForHeight || ...)" check, because it trivially passes when that bool is false. Background on this special case & why we can remove it: ======================================================= In the original flexbox implementation, we had some special-case code to be sure we didn't end up swapping in e.g. "flex-basis:-moz-min-content" for "height" in these ComputeSize functions, because that was a scenario that previously would've been prevented at the parser level (height:-moz-min-content is rejected for now), and hence may not have ended up being handled robustly. However, nowadays it'll be handled just fine in these functions, and will produce the same result as our special-case exception tries to achieve. In particular, for a nsFrame that is a flex item in a flex container with a vertical main axis (the scenario that these special cases are catching): - If the (vertical) main axis is this nsFrame's inline axis (i.e. if this nsFrame has a vertical writing-mode), then Stylo actually converts enumerated flex-basis values like "-moz-min-content" to "auto" at the parser level. So it's not actually possible to get a computed "flex-basis" of -moz-min-content, in that scenario. - Otherwise, i.e. if the (vertical) main axis is this nsFrame's block axis, then these ComputeSize functions will now end up getting an enumerated "blockStyleCoord" (really pointing to flexBasis), but that'll still end up being treated like 'auto'. This happens by virtue of ComputeSize's calls to ComputeAutoSize (which initializes the tentative bsize value to NS_UNCONSTRAINEDSIZE) and to nsLayoutUtils::IsAutoBSize (which returns "true" for eStyleUnit_Enumerated values and then makes us leave the ComputeAutoSize result unperturbed).
45384697a0c31a57255ff51d72c106c0b7f0635c: Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj draft
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 11:48:18 +1100 - rev 774593
Push 104438 by nnethercote@mozilla.com at Thu, 29 Mar 2018 04:48:25 +0000
Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU
f3c8d956d449ce6b30ee756a0a9cf699509539fc: Bug 1438688, part 6 - Compile XPT information to C++ at build time. r=glandium,njn draft
Andrew McCreight <continuation@gmail.com> - Mon, 12 Mar 2018 10:30:35 -0700 - rev 774592
Push 104437 by bmo:continuation@gmail.com at Thu, 29 Mar 2018 04:42:35 +0000
Bug 1438688, part 6 - Compile XPT information to C++ at build time. r=glandium,njn 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
d319ab3fdf65460f9a178d0b576dbb42b7f3f2be: Bug 1438688, part 5 - Merge XPTInterfaceDirectoryEntry and XPTInterfaceDescriptor. r=njn draft
Andrew McCreight <continuation@gmail.com> - Mon, 12 Mar 2018 13:36:15 -0700 - rev 774591
Push 104437 by bmo:continuation@gmail.com at Thu, 29 Mar 2018 04:42:35 +0000
Bug 1438688, part 5 - Merge XPTInterfaceDirectoryEntry and XPTInterfaceDescriptor. r=njn 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
7f2bed65a3eb36cf719a2d8e920a9d13d4cc741e: Bug 1438688, part 4 - Hoist arrays to XPTHeader. r=njn draft
Andrew McCreight <continuation@gmail.com> - Wed, 28 Feb 2018 15:12:07 -0800 - rev 774590
Push 104437 by bmo:continuation@gmail.com at Thu, 29 Mar 2018 04:42:35 +0000
Bug 1438688, part 4 - Hoist arrays to XPTHeader. r=njn 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
861b2eeb6a15103f9a26b6f56a8fd549e2759bbe: Bug 1438688, part 3 - Remove XPT files from the packaging process. r=glandium draft
Andrew McCreight <continuation@gmail.com> - Mon, 05 Mar 2018 14:27:29 -0800 - rev 774589
Push 104437 by bmo:continuation@gmail.com at Thu, 29 Mar 2018 04:42:35 +0000
Bug 1438688, part 3 - Remove XPT files from the packaging process. r=glandium 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
20712b7e9e674e3d583df3917120d438cabdf2f4: Bug 1438688, part 2b - Eliminate XPTHeader data structure. r=njn draft
Andrew McCreight <continuation@gmail.com> - Tue, 27 Mar 2018 14:04:01 -0700 - rev 774588
Push 104437 by bmo:continuation@gmail.com at Thu, 29 Mar 2018 04:42:35 +0000
Bug 1438688, part 2b - Eliminate XPTHeader data structure. r=njn 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
db15a535dbc26ef9cae893274265bf2b8416b3f7: Bug 1438688, part 2 - Load XPT information from a static variable instead of a file. r=njn draft
Andrew McCreight <continuation@gmail.com> - Wed, 28 Feb 2018 12:51:39 -0800 - rev 774587
Push 104437 by bmo:continuation@gmail.com at Thu, 29 Mar 2018 04:42:35 +0000
Bug 1438688, part 2 - Load XPT information from a static variable instead of a file. r=njn 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
c3c70554ead64f212bf9bbb8ab5392fa376c88e4: Bug 1438688, part 1 - Add methods for accessing arrays in xpt_struct.h. r=njn draft
Andrew McCreight <continuation@gmail.com> - Wed, 28 Feb 2018 10:07:45 -0800 - rev 774586
Push 104437 by bmo:continuation@gmail.com at Thu, 29 Mar 2018 04:42:35 +0000
Bug 1438688, part 1 - Add methods for accessing arrays in xpt_struct.h. r=njn 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
c7b7d9ddb0f0288b3ef42e35009c2beaff835118: Bug 1397624 Start updating tests draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Mar 2018 23:35:04 -0500 - rev 774585
Push 104436 by bmo:tom@mozilla.com at Thu, 29 Mar 2018 04:36:07 +0000
Bug 1397624 Start updating tests MozReview-Commit-ID: KxQC7uJTV01
2a1f697918f7a09328a8ef8dc8e36092b7d1a228: Bug 1397624 Add a new privacy.firstparty.isolate.pbmode.enabled pref to enable FPI in PBM only draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Mar 2018 23:34:47 -0500 - rev 774584
Push 104436 by bmo:tom@mozilla.com at Thu, 29 Mar 2018 04:36:07 +0000
Bug 1397624 Add a new privacy.firstparty.isolate.pbmode.enabled pref to enable FPI in PBM only MozReview-Commit-ID: KFaXLCf6j0n
e5294bacd27cd4b5002f6f70f2227ea27f13f988: Bug 1337157 Disable WEBGL_debug_renderer_info when Resist Fingerprinting is active r?jgilbert draft
Tom Ritter <tom@mozilla.com> - Mon, 26 Mar 2018 23:48:35 -0500 - rev 774583
Push 104436 by bmo:tom@mozilla.com at Thu, 29 Mar 2018 04:36:07 +0000
Bug 1337157 Disable WEBGL_debug_renderer_info when Resist Fingerprinting is active r?jgilbert MozReview-Commit-ID: F7LCweFIPtM
7b324719996a94fc15afa33ac8bf52847466e85b: Bug 1447592 Do not reset the Spoof English pref after disabling Resist Fingerprinting r?johannh draft
Tom Ritter <tom@mozilla.com> - Mon, 26 Mar 2018 23:33:39 -0500 - rev 774582
Push 104436 by bmo:tom@mozilla.com at Thu, 29 Mar 2018 04:36:07 +0000
Bug 1447592 Do not reset the Spoof English pref after disabling Resist Fingerprinting r?johannh MozReview-Commit-ID: MMWYfmUTOr
8aa9a06b923510de11df59012f149f3d489bc82f: Bug 1449835 Do not compile Windows x64 Crash Test Assembly for MinGW draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Mar 2018 13:23:33 -0500 - rev 774581
Push 104435 by bmo:tom@mozilla.com at Thu, 29 Mar 2018 04:34:44 +0000
Bug 1449835 Do not compile Windows x64 Crash Test Assembly for MinGW The assembly file uses the wrong syntax and MinGW cannot compile it. (Also, gcc doesn't recognize it, because it ends in .asm and not .s.) MozReview-Commit-ID: 5mHPi8PVio3
47f404fbc465e0d1142c2e2a6f674c6465a4b024: Bug 1449835 Do not compile Windows x64 Crash Test Assembly for MinGW r?ted draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Mar 2018 13:23:33 -0500 - rev 774580
Push 104434 by bmo:tom@mozilla.com at Thu, 29 Mar 2018 04:32:53 +0000
Bug 1449835 Do not compile Windows x64 Crash Test Assembly for MinGW r?ted The assembly file uses the wrong syntax and MinGW cannot compile it. (Also, gcc doesn't recognize it, because it ends in .asm and not .s.) MozReview-Commit-ID: 5mHPi8PVio3
c9306c0260d52c49f5144d96bd4dcceee718e2e1: Bug 1449834 Define SK_JUMPER_USE_ASSEMBLY as 0, not False r?lsalzman draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Mar 2018 12:07:59 -0500 - rev 774579
Push 104433 by bmo:tom@mozilla.com at Thu, 29 Mar 2018 04:29:38 +0000
Bug 1449834 Define SK_JUMPER_USE_ASSEMBLY as 0, not False r?lsalzman When defined as 'False', we get -USK_JUMPER_USE_ASSEMBLY. When it's undefined, it will be defined as 1. What we actually need is -DSK_JUMPER_USE_ASSEMBLY=0 MozReview-Commit-ID: 7s38sefdvgv
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip