To setup memory reporter on socket process, this patch modifies the PSocketProcess protocol to implement the same memory reporting functions as the PContent and PGPU protocols.
Differential Revision: https://phabricator.services.mozilla.com/D14155
--HG--
extra : moz-landing-system : lando
The only visible change from this change is that telemetry will be
discontinuous. The owners for the relevant telemetry probes have
reviewed this and indicated that this discontinuity is OK.
nsTimerEvent goes through a multi-step initialization for reasons that
are lost to time. We are also seeing peculiar crashes in
`nsTimerEvent::SetTimer()` that are only explainable by `SetTimer`
finding a non-null pointer where there should have been a null pointer.
The compiler ought to have been able to optimize those bits away, but no
matter: we can do the job ourselves and make the code clearer.
Since we only call `SetTimer` once, we should just move its work into
nsTimerEvent's constructor.
Doing this code movement separately will ideally make the next part of
this work easier to review. The idea is that we want to extract all the
necessary information from `timer` before we pass ownership of it into
the newly-allocated nsTimerEvent.
Unlike many of our uses of `new`, nsTimerEvent has its own definition of
`operator new`, to ensure instances are allocated through
TimerEventAllocator. And allocating with TimerEventAllocator can fail.
Later changes, however, want to assume that constructing an nsTimerEvent
can't fail, which is difficult to guarantee with the current structure.
To make that guarantee, we need to make explicit what calling `new`
does: there's an "allocate memory" step and a "construct the object"
step. The first part can fail, and that's what we care about here.
Once we have a chunk of memory, we can construct the object as normal,
secure in the knowledge that calling (placement) `new` is now guaranteed
to succeed.
The layout module initializes a bunch of things, specifically
XPConnect. And if we're not loading chrome manifests, we shouldn't need
to initialize the layout module.
Checking that the current process type is not equal to some value
requires adding code when new process types are added. Since it seems
reasonable to assume that all new process types aren't going to require
chrome manifests, let's make the code reflect that assumption as well,
and reduce the number of places you need to touch when adding a new
process type.
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This will be needed for the next patches since the cast from nsIDocument* to
nsISupports* will become ambiguous, and I don't really want to replace all users
of nsCOMPtr<nsIDocument> with RefPtr.
We have ToSupports to handle this, so use it.
Differential Revision: https://phabricator.services.mozilla.com/D15350
This was necessary back when it still contained a lot of xpcom code, but
shouldn't be necessary now that it only contains two objects.
Differential Revision: https://phabricator.services.mozilla.com/D15168
--HG--
extra : moz-landing-system : lando
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
Move js/src/jsapi.h declarations related to promises and job queues into their
own public header file, js/public/Promise.h. Change the compilation units that
need these declarations to #include the new header.
There should be no changes to the actual functionality here, simply moving the
code to a new file, and removing the "JS" prefix from some typedefs which are
now in the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D13345
--HG--
extra : moz-landing-system : lando
Fails with clang trunk:
"type of UTF-8 string literal will change from array of const char to array of const char8_t in C++2a"
otherwise
Differential Revision: https://phabricator.services.mozilla.com/D14696
--HG--
extra : moz-landing-system : lando
This backs out the main patch landed earlier in bug 1194856 and the
patch from bug 1225004.
Differential Revision: https://phabricator.services.mozilla.com/D14050
--HG--
extra : moz-landing-system : lando
vpx_mem_set_functions support is only enabled when
MOZ_VPX_NO_MEM_REPORTING is not set. It is currently set unconditionally
when building with the in-tree libvpx. When building with system libvpx,
it is set when the vpx_mem_set_functions can't be found in the system
libvpx library.
Upstream removed the vpx_mem_set_functions function in version 1.5, and
we require at least that version, meaning, in practice,
MOZ_VPX_NO_MEM_REPORTING is now always set.
We might as well remove the define and the code that's conditional to
not being defined.
Differential Revision: https://phabricator.services.mozilla.com/D14517
--HG--
extra : moz-landing-system : lando
We introduce GenericNonExclusivePromise that can be used to explicitly state than non-exclusive use is needed
We temporarily disable the assertion ensuring a promise is used exclusively when needed to allow for things to settle.
Differential Revision: https://phabricator.services.mozilla.com/D14025
--HG--
extra : moz-landing-system : lando
This has benefits both in terms of performance and memory usage. Aside from
the obvious savings of not loading additional JS scripts in every process,
this also allows us to move more of our expensive data collection work to a
background thread, where it doesn't risk janking both parent and content
processes.
MozReview-Commit-ID: 2A593R7bIKB
Differential Revision: https://phabricator.services.mozilla.com/D13872
--HG--
extra : rebase_source : ec634ee3a3b975809f542aa8077ad32236781452
Change nsMacUtilsImpl::GetAppPath() to not depend on the app bundle ending in ".app".
Differential Revision: https://phabricator.services.mozilla.com/D13682
--HG--
extra : moz-landing-system : lando
Replace with just unwrapping the key, since there are no users that return anything else for a delegate.
--HG--
extra : rebase_source : e72b825121ca3493364c9347f65e5dddd1ef53e0
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
nsCRTGlue.cpp has a few data tables that get broken up badly by
clang-format, so just disable the formatting. There are some more
tables in this file, but the arrangement doesn't seem to matter for
them.
The bloat log header is just a little bit of ASCII art, so just ignore
it in formatting so it is easier to read.
MOZ_COLLECT_REPORT uses very wide string constants that get rewrapped
in an ugly way by clang-format, so just disable the formatting for
them.
Depends on D13185
Differential Revision: https://phabricator.services.mozilla.com/D13186
--HG--
extra : moz-landing-system : lando
clang-format doesn't seem to reflow text when a single string constant
is represented as multiple lines of string literals to fit within 80
columns. Instead, if a single string literal is too long, it breaks
off a piece and moves it to the next line, which leads to a bunch of
choppy short string bits. The resulting string literals are still a
bit choppy, mostly because I didn't want to break up the long names of
prefs.
Here's an example of what I mean:
|--- max width --- |
"some long string literal"
"is here but it goes on for multiple lines"
This gets turned into:
|--- max width --- |
"some long string "
"literal"
"is here but it "
"goes on for multiple lines"
My patch manually would turn this into:
|--- max width --- |
"some long string "
"literal is here "
"but it goes on "
"for multiple lines"
The strings in my patch don't always end up at column 80, because the
width is set to work with wherever clang format ends up actually
indenting them.
There are more instances of this problem when MOZ_COLLECT_REPORT is
used, but that can be dealt with in another bug. There are a ton of
them.
Depends on D13184
Differential Revision: https://phabricator.services.mozilla.com/D13185
--HG--
extra : moz-landing-system : lando
Clang format does not always reflow comments correctly to get them
within 80 columns.
The major categories of failures I have noticed in xpcom/ are:
- Comments that are lists. I fixed these by manually getting them so
they'll be within 80 columns after clang-format runs.
- Comments intermixed with lists of things like enums, initializers,
or even fields in a class. It doesn't seem to associate the comment
with the item in the list correctly. The worst cases of these happen
when it changes initializer lists from having commas at the start of
each item to having them at the end. In the initializer comma cases,
I fixed them by making the commas at the end, so clang-format won't
mix things up. For other cases, I often moved the comment for an
item onto its own line, because it was not possible to have both the
comment and the item on the same line and stay within 80 columns.
- One odd case is nsEnumeratorUtils.cpp, where the end of line comment
after a NS_DECL macro confused clang-format and made it stop
realizing that the NS_DECL thing was a complete statement. I also
added a blank line to that file before a declaration because I think
that is better.
Depends on D13183
Differential Revision: https://phabricator.services.mozilla.com/D13184
--HG--
extra : moz-landing-system : lando
Clang format makes this code look pretty bad, but I think it is safe
to just remove it.
Depends on D13182
Differential Revision: https://phabricator.services.mozilla.com/D13183
--HG--
extra : moz-landing-system : lando
We're paying two function calls from Gecko_AddRefAtom /
Gecko_ReleaseAtom for no good reason, plus it's simple enough it's probably
worth to inline it anyway for C++ callers.
Differential Revision: https://phabricator.services.mozilla.com/D12860
--HG--
extra : moz-landing-system : lando
The core loop of Iterator::Next() requires multiple branches, one to
check for entry liveness and one to check for wraparound. We can
rewrite this to use masking instead, as well as iterating only over the
hashes, and reconstructing the entry pointer when we know we've reached
a live entry. This change cuts the time taken on the collections
benchmark by the iteration portion in half.
As discussed in the previous commit message, PLDHashTable's storage
wastes space for common entry types. This commit reorganizes the
storage to store all the hashes packed together, followed by all the
entries, which eliminates said waste.
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
The only place where this is used where the const-ness matters is in
AddressEntry, and that use const_cast's away the const-ness. So let's
just ditch the method that attempts to return const pointers.
This change is satisfying insofar as it removes a load from every
iteration step over the hashtable, but it doesn't seem to affect
our collection benchmarks in any way. The change does not make
iterators any larger, as there is padding at the end of the iterator
structure on both 32- and 64-bit platforms.
* Changes the format of the blocklist from a list of characters to a list of
character ranges. Binary search still works, and it is easier to include
large ranges of characters in the blocklist.
* Moves logic for handling the blocklist to IDNBlocklistUtils.h/.cpp
* Changes NS_EscapeURL to take a function that determines if a character
is blocked. This way the type of the array doesn't matter.
Differential Revision: https://phabricator.services.mozilla.com/D12210
--HG--
extra : moz-landing-system : lando
Move constructors and assignment operators are expected to be safe and
infallible. In debug mode, nsCOMPtr's move functions called a test function
that modified the pointee's refcount -- a potentially thread unsafe operation
that also opened the door to assertion failures if the pointee implemented
some access checks in AddRef() or Release(). This commit removes this function
call in those two functions.
Differential Revision: https://phabricator.services.mozilla.com/D12422
--HG--
extra : moz-landing-system : lando
(Unless there were other profiler actions, as I'm not sure yet whether it would
be safe to skip them when the profiler is paused; another bug should
investigate that.)
Differential Revision: https://phabricator.services.mozilla.com/D11308
--HG--
extra : moz-landing-system : lando
Andreea Pavel
Kershaw Chang
Cameron McCormack
Henri Sivonen
Olli Pettay
Bogdan Tara
Nathan Froyd
Eric Rahm
Randell Jesup
Razvan Maries
Jan de Mooij
bitnotri
Emilio Cobos Álvarez
Daniel Varga
Gabriele Svelto
Jon Coppeard
Sylvestre Ledru
quasicomputational
Mike Hommey
Michael Froman
Jan Henning
Ehsan Akhgari
Kris Maglione
arthur.iakab
Jim Blandy
Jonathan Kingston
Andrea Marchesini
Cosmin Sabou
Jean-Yves Avenard
Masatoshi Kimura
Coroiu Cristina
Brindusan Cristian
ffxbld
Haik Aftandilian
Jorg K
Brian Hackett
Steve Fink
Tooru Fujisawa
Benjamin Bouvier
Andrew McCreight
Jeff Walden
Valentin Gosu
Tim Nguyen
Yaron Tausky
Gerald Squelart
Paolo Amadini