They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : f172424042fab18a514201ba4b6c67c03c209cdb
This patch defines NS_ERROR_EDITOR_DESTROYED error code as an editor module
specific error code.
And creates TextEditRules::CanHandleEditAction() to check if the instance
can keep handling edit action.
MozReview-Commit-ID: 4qECwNBO0yz
--HG--
extra : rebase_source : a925a9b6840d4d06e2792b9fe276e062288b0806
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
When memory-pressure events were first used in an e10s environment it was
to implement memory minimization from about:memory. However when low memory
detection was first introduced in Firefox OS an issue arised with this scheme:
every process was using a kernel-based low-latency mechanism to detect low
memory scenarios and send memory-pressure events; but the main process events
were also being forwarded to all child processes causing listeners to be
triggered twice. Because of this -no-forward events were introduced and used.
Currently however low-memory is detected via polling, so there will always be
a significant delay between the beginning of the low-memory scenario and its
detection. Because of this there is no value in having content processes poll
on their own and it's best to have only the main process do it and then
forward the memory-pressure events to all child processes.
MozReview-Commit-ID: AMQOsEgECme
--HG--
extra : rebase_source : 1b408b31dd27940981407f50f2e5f07e354b16d7
This patch introduces a new polling mechanism to detect low-memory scenarios.
The timer fires at a relatively slow pace and stops whenever the user stops
interacting with Firefox to avoid consuming power needlessly. The polling rate
is up to 3 orders of magnitude slower than the current tracker and is
throttled when memory is running low. It also doesn't suffer from data races
that were possible with existing tracker.
Contrary to the old available memory tracker which relied on a
Windows-specific mechanism, this one could be made to work on other platforms
too. The current implementation only supports Windows 64-bit builds though.
MozReview-Commit-ID: CFHuTDqjPbL
--HG--
extra : rebase_source : 92d1f801cc680f9fde8ecfa46c570e3c562a3d01
This type is fairly simple on the idl parsing side of things. I handle it in the
same way that special types such as ns[C]String, nsid, and jsval are handled, by
using a special native type.
The logic for converting the value between C++ and JS follows the existing logic
from the nsISupports <=> JS Promise conversions.
"alloc-failure" is completely unused apart from the description text in nsI-
Memory.idl (and has been since before Firefox 17), while "lowering-priority" is
still being checked for in the PuppetWidget, but otherwise unused as well since
the feature using it was decommissioned in bug 1234176.
Since we're touching the PuppetWidget code anyway, we take the opportunity to
add a check for "low-memory-ongoing" instead, since similar as to how things
used to be with "lowering-priority", we want to drop the LayerManager's cached
resources only when receiving a real full memory-pressure event, but not for
subsequent ongoing notifications.
MozReview-Commit-ID: HL03SOU8axe
--HG--
extra : rebase_source : c988769df36d8d77f4770c71d5c5e0d75c3b99af
For some reason, the CC spends a lot of time tracing jsids on
ObjectGroups when an addon is installed. This patch avoids that by
adding a canSkipJsids flag to JSTracer, and using it in
ObjectGroup::traceChildren. If this is true, then the tracer is free
to not report every jsid. This flag is set to true for the two CC
tracers.
MozReview-Commit-ID: CWFqQEr0SxV
--HG--
extra : rebase_source : cc31c22717f8990166454db191e0d40c145e09f0
Use fatal MOZ_ASSERT or non-fatal NS_ASSERTION instead.
MozReview-Commit-ID: 1QAsgoWpXDn
--HG--
extra : source : 9ca972b6b3e7d3b576e20a0bf412df51d82aad9f
extra : intermediate-source : a909a9d7bc9a53095e963a4bea45f4fc4aa85b72
...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.
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
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
clang-tidy is complaining about an extra else in
NS_INTERFACE_MAP_ENTRIES_CYCLE_COLLECTION. Not hurting anything, but
could be cleaned up anyways.
MozReview-Commit-ID: 36Lkdhs3fyN
--HG--
extra : rebase_source : 74088c9c2668f43d55133be240d4591880b60dab