Bug 1471743 - remove STRICT_FAKE_SYMLINKS code from nsLocalFileWin; r=erahm We don't define STRICT_FAKE_SYMLINKS anywhere, so this is dead code.

Bug 1402247 - Use encoding_rs for XPCOM string encoding conversions. r=Nika,erahm,froydnj. Correctness improvements: * UTF errors are handled safely per spec instead of dangerously truncating strings. * There are fewer converter implementations. Performance improvements: * The old code did exact buffer length math, which meant doing UTF math twice on each input string (once for length calculation and another time for conversion). Exact length math is more complicated when handling errors properly, which the old code didn't do. The new code does UTF math on the string content only once (when converting) but risks allocating more than once. There are heuristics in place to lower the probability of reallocation in cases where the double math avoidance isn't enough of a saving to absorb an allocation and memcpy. * Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized but a single non-ASCII code point pessimized the rest of the string. The new code tries to get back on the fast ASCII path. * UTF-16 to Latin1 conversion guarantees less about handling of out-of-range input to eliminate an operation from the inner loop on x86/x86_64. * When assigning to a pre-existing string, the new code tries to reuse the old buffer instead of first releasing the old buffer and then allocating a new one. * When reallocating from the new code, the memcpy covers only the data that is part of the logical length of the old string instead of memcpying the whole capacity. (For old callers old excess memcpy behavior is preserved due to bogus callers. See bug 1472113.) * UTF-8 strings in XPConnect that are in the Latin1 range are passed to SpiderMonkey as Latin1. New features: * Conversion between UTF-8 and Latin1 is added in order to enable faster future interop between Rust code (or otherwise UTF-8-using code) and text node and SpiderMonkey code that uses Latin1. MozReview-Commit-ID: JaJuExfILM9

Bug 1399789 - nsSubstringSplitter/nsCSubstringSplitter is not defined anymore; r=erahm

Bug 1478942 - Convert UniquePtr<SimpleEdgeRange> back to UniquePtr<EdgeRange> to return an EdgeRange. r=erahm

Bug 1478879 - Remove Range/Enum use in Bench.cpp. r=erahm MozReview-Commit-ID: FbAlDLHWA55

Bug 1478879 - Remove Range/Enum use in DMD. r=erahm MozReview-Commit-ID: HTfiFlBluJ1

Bug 1478879 - Remove Range/Enum use in Bench.cpp. r=erahm

Bug 1478879 - Remove Range/Enum use in DMD. r=erahm

Bug 1477626 - Use mozilla::HashTable instead of JS::HashTable in DMD. r=erahm Also use mozilla::HashNumber where appropriate. MozReview-Commit-ID: BTq0XDS5UfQ

Bug 1461450 - Part 2: Add tests for AutoTArray move constructors, r=erahm

Bug 1477626 - Use mozilla::HashTable instead of JS::HashTable in DMD. r=erahm Also use mozilla::HashNumber where appropriate. MozReview-Commit-ID: BTq0XDS5UfQ

Bug 1415980 - make hash keys movable and not copyable; r=erahm Everything that goes in a PLDHashtable (and its derivatives, like nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack of enforcement, copy constructors for these derived classes didn't explicitly invoke the copy constructor for PLDHashEntryHdr (and the compiler didn't invoke the copy constructor for us). Instead, PLDHashTable explicitly copied around the bits that the copy constructor would have. The current setup has two problems: 1) Derived classes should be using move construction, not copy construction, since anything that's shuffling hash table keys/entries around will be using move construction. 2) Derived classes should take responsibility for transferring bits of superclass state around, and not rely on something else to handle that. The second point is not a huge problem for PLDHashTable (PLDHashTable only has to copy PLDHashEntryHdr's bits in a single place), but future hash table implementations that might move entries around more aggressively would have to insert compensation code all over the place. Additionally, if moving entries is implemented via memcpy (which is quite common), PLDHashTable copying around bits *again* is inefficient. Let's fix all these problems in one go, by: 1) Explicitly declaring the set of constructors that PLDHashEntryHdr implements (and does not implement). In particular, the copy constructor is deleted, so any derived classes that attempt to make themselves copyable will be detected at compile time: the compiler will complain that the superclass type is not copyable. This change on its own will result in many compiler errors, so... 2) Change any derived classes to implement move constructors instead of copy constructors. Note that some of these move constructors are, strictly speaking, unnecessary, since the relevant classes are moved via memcpy in nsTHashtable and its derivatives.

Bug 1461450 - Part 2: Add tests for AutoTArray move constructors, r=erahm

Bug 1469603 - Use a recursive lock in crash reporter callbacks that might be called synchronously. r=erahm, a=RyanVM

Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread directly, for some reason. MozReview-Commit-ID: 2Qg28EqDwM7

Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange This automatically gets us wrappers (and therefore memory statistics) for Stylo threads, JS HelperThreads, and any other non-nsThread threads that we already register with the profiler. MozReview-Commit-ID: 8ZPjb0ojyWp

Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell For ordinary JS helper threads, we can update names and create wrappers using the existing thread profiler hooks, but we still need to update their default stack sizes to avoid huge pages. For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but only sometimes. And we never use a reasonable stack size. MozReview-Commit-ID: EuR3gL5JATL

Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld MozReview-Commit-ID: FvGhq6nhIde

Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm MozReview-Commit-ID: 1JKxWeejqzi

Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread directly, for some reason. MozReview-Commit-ID: 2Qg28EqDwM7

Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange This automatically gets us wrappers (and therefore memory statistics) for Stylo threads, JS HelperThreads, and any other non-nsThread threads that we already register with the profiler. MozReview-Commit-ID: 8ZPjb0ojyWp

Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell For ordinary JS helper threads, we can update names and create wrappers using the existing thread profiler hooks, but we still need to update their default stack sizes to avoid huge pages. For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but only sometimes. And we never use a reasonable stack size. MozReview-Commit-ID: EuR3gL5JATL

Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld MozReview-Commit-ID: FvGhq6nhIde

Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm MozReview-Commit-ID: 1JKxWeejqzi

Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread directly, for some reason. MozReview-Commit-ID: 2Qg28EqDwM7

Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange This automatically gets us wrappers (and therefore memory statistics) for Stylo threads, JS HelperThreads, and any other non-nsThread threads that we already register with the profiler. MozReview-Commit-ID: 8ZPjb0ojyWp

Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell For ordinary JS helper threads, we can update names and create wrappers using the existing thread profiler hooks, but we still need to update their default stack sizes to avoid huge pages. For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but only sometimes. And we never use a reasonable stack size. MozReview-Commit-ID: EuR3gL5JATL

Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld MozReview-Commit-ID: FvGhq6nhIde

Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm MozReview-Commit-ID: 1JKxWeejqzi

Bug 1478820 - Stop manually synchronizing VTYPE_ and nsXPTTypeTag, r=erahm Reviewers: erahm! Tags: #secure-revision Bug #: 1478820 Differential Revision: https://phabricator.services.mozilla.com/D2449

Bug 1478787: Rebuild stale SharedMap on Has() call. r?erahm MozReview-Commit-ID: 5aFVBNQW4QR

Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread directly, for some reason. MozReview-Commit-ID: 2Qg28EqDwM7

Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange This automatically gets us wrappers (and therefore memory statistics) for Stylo threads, JS HelperThreads, and any other non-nsThread threads that we already register with the profiler. MozReview-Commit-ID: 8ZPjb0ojyWp

Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell For ordinary JS helper threads, we can update names and create wrappers using the existing thread profiler hooks, but we still need to update their default stack sizes to avoid huge pages. For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but only sometimes. And we never use a reasonable stack size. MozReview-Commit-ID: EuR3gL5JATL

Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld MozReview-Commit-ID: FvGhq6nhIde

Bug 1478787: Rebuild stale SharedMap on Has() call. r?erahm MozReview-Commit-ID: 5aFVBNQW4QR

Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread directly, for some reason. MozReview-Commit-ID: 2Qg28EqDwM7

Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange This automatically gets us wrappers (and therefore memory statistics) for Stylo threads, JS HelperThreads, and any other non-nsThread threads that we already register with the profiler. MozReview-Commit-ID: 8ZPjb0ojyWp

Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell For ordinary JS helper threads, we can update names and create wrappers using the existing thread profiler hooks, but we still need to update their default stack sizes to avoid huge pages. For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but only sometimes. And we never use a reasonable stack size. MozReview-Commit-ID: EuR3gL5JATL

Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld MozReview-Commit-ID: FvGhq6nhIde

Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm MozReview-Commit-ID: 1JKxWeejqzi

Bug 1478337 - avoid useless work in nsTArray::RemoveElement; r=erahm When removing an element that exists in the array, there's no need to perform extra bounds checks for actually removing the element; the presence of the element guarantees that we have a valid index and a valid range to remove. So split RemoveElementsAt into a safe interface and an unsafe interface, and let RemoveElement call the latter as an internal optimization. The same logic applies to RemoveElementSorted. We call RemoveElement depressingly often, so this is a nice little win.

Bug 1477626 - Use mozilla::HashTable instead of JS::HashTable in DMD. r=erahm Also use mozilla::HashNumber where appropriate. MozReview-Commit-ID: BTq0XDS5UfQ

Bug 1477626 - Use mozilla::HashTable instead of JS::HashTable in DMD. r=erahm Also use mozilla::HashNumber where appropriate. MozReview-Commit-ID: E7m4PWG3IG7

Bug 1461450 - Part 2: Add tests for AutoTArray move constructors, r=erahm

Bug 1476168: Only parse /proc/self/smaps once per memory reporter cycle. r?erahm MozReview-Commit-ID: E28l5GXSg1r

Bug 1477512: Part 5 - Rearrange the fields of nsThread for better packing. r=erahm This takes 16 bytes off of the allocated size of each instance. MozReview-Commit-ID: AhfN6MWvVL1

Bug 1477512: Part 4 - Add memory reporter for thread kernel stack sizes. r=erahm We don't have a way to determine these at runtime, but for Windows and Linux, the values are known and predictable. MozReview-Commit-ID: 57LMJLzl762

Bug 1477512: Part 3 - Add memory reporter for thread heap overhead. r=erahm This adds reporting for heap overhead from nsThread and PRThread wrappers, as well as thread event queues. It does not, currently, include overhead from PlatformThread or js::Thread wrappers. MozReview-Commit-ID: 6DkvbbkjHXm

Bug 1477512: Part 2 - Add memory reporting functions to nsThread. r=erahm MozReview-Commit-ID: 9wlNLaY9y8I