These lines of code are within the #else section of the #ifndef MOZ_GECKO_PROFILER
at the top of the file, so MOZ_GECKO_PROFILER is always defined for them.
MozReview-Commit-ID: IxRYexzZH0G
--HG--
extra : rebase_source : 302e5515323a63f145eed75a2b66a04fbde052e5
To add test for startProfiler's parameters on devtools, nsIProfilerStartParams
changes to scriptable.
MozReview-Commit-ID: 3Rf39NzsND1
--HG--
extra : rebase_source : 2b4fc908e7c611a36ac8766b9ce7ccd55f2c5620
This changeset changes behavior.
If the profile is streamed before any JSContext has gone away, we now iterate
over the entire buffer twice (per thread): First, to collect information about
JIT frames, and then again when we build the JSON for the samples. The first
traversal stores small pieces of JSON for JIT fromes in individual strings, and
the second iteration splices those strings into the thread JSON's frame table.
When the JSContext for a thread goes away, we no longer build JSON for samples,
and we don't reset the profiler buffer. We now only build the JSON for JIT
frames. Once the complete profile is requested and we build samples for it, we
iterate over the entire buffer, and look up the cached JIT frame information for
JitReturnAddr entries from the correct range. Different parts of the buffer may
correspond to the life time of different JSContexts: For each JSContext we will
have one range in the JITFrameInfo, and we can look up the correct range based
on the buffer position of the JitReturnAddr entry that we're processing.
This new way of doing things has multiple advantages:
- We no longer reset the buffer, so we no longer lose information about other
threads.
- All threads from a given process now always have sample data for the same
time range. Before this change, the "partial profile" from a thread that
lost its JSContext could extend further into the past than the other threads'
profiles.
- Requesting profiles multiple times now has more consistent results. Before
this change, the first requested profile would include the partial profile,
but then the partial profile was discarded. And the second requested profile
would not contain any data for the time before the JSContext went away.
- We now do less work when a thread's JSContext goes away. This should
decrease the interruption time.
MozReview-Commit-ID: 3KhnPtBijna
--HG--
extra : rebase_source : 2ef5ac933e4db1c98526a2b36147ff031893de9e
extra : intermediate-source : d63b04327077d1ef55f509b365cd2693905b0733
extra : source : f2d8c993aa2c16bc491c55179d545f5a2c727391
In an upcoming patch we'll want to initialize mUniqueStrings by stealing
another object's UniqueJSONStrings, but UniqueJSONStrings itself is not
move-constructible. But UniquePtr is.
Making UniqueJSONStrings itself move-constructible would be a bit tricky
because it has a SpliceableChunkedJSONWriter which is not move-constructible;
and making SpliceableChunkedJSONWriter move-constructible is hard because
there's no obvious "empty but valid" state that we could leave a moved-out-of
SpliceableChunkedJSONWriter in; for example, it expects to have a non-null
WriteFunc at all times.
MozReview-Commit-ID: Q6o61HFTiD
--HG--
extra : rebase_source : e1073be9892cf7cfd6ca4f2562ce939690b3b4d7
This also renames FlushSamplesAndMarkers to NotifyAboutToLoseJSContext.
MozReview-Commit-ID: FWinMi85yDZ
--HG--
extra : rebase_source : 6d8bfd6937ce757108f80f43e878a2dbead318bd
This makes it clear which combinations of fields are possible.
MozReview-Commit-ID: C3PriO7nWsJ
--HG--
extra : rebase_source : 68df01f11121b09b2f2762581dc28184262abfb8
I think this file was picking up such a declaration from a different file
already, through unified builds.
MozReview-Commit-ID: 9xTB2QA86U0
--HG--
extra : rebase_source : d7b614524ebdf25a185698b6632d6f925ce08da8
nsCString is the idiomatic string class we want to use anyway. There's no need
to think about std::string here.
MozReview-Commit-ID: 1rjZAyqp13d
--HG--
extra : rebase_source : 92c4eb22876c4fc89f00104c56f92a75053284e9
nsGenericHashKey never calls this operator, as far as I can tell.
MozReview-Commit-ID: NDybMI8DOA
--HG--
extra : rebase_source : 933c12e2ef4600ea33b6c7026f539e51447fc454
This changeset changes behavior.
If the profile is streamed before any JSContext has gone away, we now iterate
over the entire buffer twice (per thread): First, to collect information about
JIT frames, and then again when we build the JSON for the samples. The first
traversal stores small pieces of JSON for JIT fromes in individual strings, and
the second iteration splices those strings into the thread JSON's frame table.
When the JSContext for a thread goes away, we no longer build JSON for samples,
and we don't reset the profiler buffer. We now only build the JSON for JIT
frames. Once the complete profile is requested and we build samples for it, we
iterate over the entire buffer, and look up the cached JIT frame information for
JitReturnAddr entries from the correct range. Different parts of the buffer may
correspond to the life time of different JSContexts: For each JSContext we will
have one range in the JITFrameInfo, and we can look up the correct range based
on the buffer position of the JitReturnAddr entry that we're processing.
This new way of doing things has multiple advantages:
- We no longer reset the buffer, so we no longer lose information about other
threads.
- All threads from a given process now always have sample data for the same
time range. Before this change, the "partial profile" from a thread that
lost its JSContext could extend further into the past than the other threads'
profiles.
- Requesting profiles multiple times now has more consistent results. Before
this change, the first requested profile would include the partial profile,
but then the partial profile was discarded. And the second requested profile
would not contain any data for the time before the JSContext went away.
- We now do less work when a thread's JSContext goes away. This should
decrease the interruption time.
MozReview-Commit-ID: 3KhnPtBijna
--HG--
extra : rebase_source : ff3d4ad4788da8f2d391b5dc465f635c1970fc0d
extra : intermediate-source : d63b04327077d1ef55f509b365cd2693905b0733
extra : source : f2d8c993aa2c16bc491c55179d545f5a2c727391
In an upcoming patch we'll want to initialize mUniqueStrings by stealing
another object's UniqueJSONStrings, but UniqueJSONStrings itself is not
move-constructible. But UniquePtr is.
Making UniqueJSONStrings itself move-constructible would be a bit tricky
because it has a SpliceableChunkedJSONWriter which is not move-constructible;
and making SpliceableChunkedJSONWriter move-constructible is hard because
there's no obvious "empty but valid" state that we could leave a moved-out-of
SpliceableChunkedJSONWriter in; for example, it expects to have a non-null
WriteFunc at all times.
MozReview-Commit-ID: Q6o61HFTiD
--HG--
extra : rebase_source : d18344cab5acc97192a69069a8c338ed112fff6c
This also renames FlushSamplesAndMarkers to NotifyAboutToLoseJSContext.
MozReview-Commit-ID: FWinMi85yDZ
--HG--
extra : rebase_source : f0608488005a4eafa7045ba6c445afbe4352567d
This makes it clear which combinations of fields are possible.
MozReview-Commit-ID: C3PriO7nWsJ
--HG--
extra : rebase_source : 6e414c46a3545a8dcc599f4d140aa5e61910b00c
I think this file was picking up such a declaration from a different file
already, through unified builds.
MozReview-Commit-ID: 9xTB2QA86U0
--HG--
extra : rebase_source : ca881f6ea8489dddba48ef0f92baa4ef10d0165e
nsCString is the idiomatic string class we want to use anyway. There's no need
to think about std::string here.
MozReview-Commit-ID: 1rjZAyqp13d
--HG--
extra : rebase_source : e67e08512927e37a82fd28f035438159717c209a
nsGenericHashKey never calls this operator, as far as I can tell.
MozReview-Commit-ID: NDybMI8DOA
--HG--
extra : rebase_source : 5a8182a5e1f2af57533ddff8848d7a772bf7eeb2
The file copies and renames make this patch look a bit confusing. Here's what
happens:
ThreadInfo.h:
Most of the code gets moved into RegisteredThread.h and ProfiledThreadData.h,
but a small piece remains in ThreadInfo.h.
ThreadInfo.cpp:
Gets split into RegisteredThread.cpp and ProfiledThreadData.cpp.
ThreadInfo.cpp itself goes away.
In the mercurial changeset, I've marked ThreadInfo.h as being copied to both
RegisteredThread.h and to ProfiledThreadData.h, and ThreadInfo.cpp as being
copied to RegisteredThread.cpp and as being renamed to ProfiledThreadData.cpp.
MozReview-Commit-ID: 1j1imAv9cTd
--HG--
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/ProfiledThreadData.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/ProfiledThreadData.h
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/RegisteredThread.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/RegisteredThread.h
extra : rebase_source : 91310691d5e46246ec03305511c1b86ab458b0b9
The file copies and renames make this patch look a bit confusing. Here's what
happens:
ThreadInfo.h:
Most of the code gets moved into RegisteredThread.h and ProfiledThreadData.h,
but a small piece remains in ThreadInfo.h.
ThreadInfo.cpp:
Gets split into RegisteredThread.cpp and ProfiledThreadData.cpp.
ThreadInfo.cpp itself goes away.
In the mercurial changeset, I've marked ThreadInfo.h as being copied to both
RegisteredThread.h and to ProfiledThreadData.h, and ThreadInfo.cpp as being
copied to RegisteredThread.cpp and as being renamed to ProfiledThreadData.cpp.
MozReview-Commit-ID: 1j1imAv9cTd
--HG--
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/ProfiledThreadData.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/ProfiledThreadData.h
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/RegisteredThread.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/RegisteredThread.h
extra : rebase_source : 91310691d5e46246ec03305511c1b86ab458b0b9
This resolves the bug where we attempted to find information about JitReturnAddr
entries which were collected with a new JSContext by asking an old JSContext.
MozReview-Commit-ID: FQrnAuwwzHU
--HG--
extra : rebase_source : d0a0c7077199dc177123bb54951f4f7238c5eaf6
This makes the JSON serialization code for optimization type info a little
easier to read.
MozReview-Commit-ID: 2auHVmp7hKw
--HG--
extra : rebase_source : 1fbcf4dc63a24822f5411a7107af0e07a703a4bf
This moves the meat of the processing from operator() into the lambda, so that
it can be read in the function that calls forEachOptimizationAttempt. Now the
person who wants to understand this code hopefully won't need to scroll up and
down as much.
MozReview-Commit-ID: H9zRf1Vbswg
--HG--
extra : rebase_source : a742fa4c076437c7af6837280f725ee4532cbf2c
This may seem like an unnecessary increase in complexity, and it probably is.
But it makes it easier to reason about lifetimes if your mind is accustomed to
Rust, which would enforce a similar solution.
MozReview-Commit-ID: kJZifbjCSU
--HG--
extra : rebase_source : a2906eb296975ca689c2c3a019c33062ba17b0f2
WriteSamples doesn't really need the ability to write strings, but always passing
a string table means that there's one less thing to worry about (one less piece of
unsafe API).
MozReview-Commit-ID: 386OEibyush
--HG--
extra : rebase_source : 4fa6428b6371cf4c3db5ad77aac06c0113b2e541
I wasn't comfortable with how Stack had a reference to the UniqueStacks object.
Now we compute new the new stack index after appending a frame by explicitly
calling a method of the UniqueStacks object.
MozReview-Commit-ID: KQAI9JNb4ag
--HG--
extra : rebase_source : 5d4c7a3f637f8e2bbd4e84c3aca65290a731a206
This also renames ForEachProfiledFrameOp::FrameHandle to ProfiledFrameHandle.
MozReview-Commit-ID: 7Jh1x2QWjXe
--HG--
extra : rebase_source : 8bb0fa15fa20215f03148cfd30ae0e41f82330fd
This gets the pseudostack from the JSContext instead of using TLS, and only
pushes a pseudo stack frame if the profiler is active.
MozReview-Commit-ID: IzT4py9H8su
--HG--
extra : rebase_source : 9962455d59e3f8b85a347f4203ac619e654fcb7c
extra : source : f15e6874f6c14f7a5e5b0cb63acd0a95ad34db4e
We extract some common framework to run profiler tests.
MozReview-Commit-ID: 7FPcH1NpJ7S
--HG--
extra : rebase_source : a487cb34c50889112eaecc8a20553365cfb70cfa
In this patch we also expose a script's compartment in jsfriendapi.h
MozReview-Commit-ID: LgoN8ANLgxI
--HG--
extra : rebase_source : a9a29e538041ac574b6b44fab166a7838fce54ac
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
We extract some common framework to run profiler tests.
MozReview-Commit-ID: 7ct5RMhwmOe
--HG--
extra : rebase_source : 01165c506a4325310c23c9be6de2f5e6f958cf00
In this patch we also expose a script's compartment in jsfriendapi.h
MozReview-Commit-ID: JGTLygZ6DK5
--HG--
extra : rebase_source : 585edbdbc74044f2d644f5046513786ee4f42a2f
Modern NDK headers all have <link.h>, so we should always include it,
and still provide shims for anything we need that's not defined in
<link.h>.
MozReview-Commit-ID: GNBDIe73RFm
--HG--
extra : rebase_source : 1246dce8a7ad201cf4f01de8e4912217636f1fc8
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
We don't support Android for Gecko Profiler extension yet.
So for investigating arm issue, I would like to add initial support of
Gecko Profiler for Linux/arm.
--HG--
extra : rebase_source : f936a97a87b7eea2ebfefe3cbc7f8791bc90d03a
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Modern NDK headers all have <link.h>, so we should always include it,
and still provide shims for anything we need that's not defined in
<link.h>.
MozReview-Commit-ID: GNBDIe73RFm
--HG--
extra : rebase_source : f1f2eddc73dc1accb3a1eb8445600b015e9e7d52
When the Gecko Profiler runs, we keep samples and markers for threads in
some occasions (eg when a Worker ends). But we fail to account for the
case where these threads have output no sample and no marker yet.
MozReview-Commit-ID: 2IEghD0v5Qd
--HG--
extra : rebase_source : b1af41c2d24b92c278922940151093f8b7d197db
We no longer support Android/armv6 and we requires NEON for Android/arm, so
we can remove armv6 support for Android.
MozReview-Commit-ID: Hh17BTyE0wR
--HG--
extra : rebase_source : 57e043ecb1bb57a026c0b656b82768b899ddae78
Fixes the LUL unwind test cases (viz, gtest LulIntegration.unwind_consistency)
when built with Clang 5.
* Increases the test stack size, LUL_UNIT_TEST_STACK_SIZE, from 16KB to
32KB, since 16KB is gives inadequate margin for the test cases used, and
is actually too small when with building with ASan enabled.
* In the generated test functions, uses write() calls that do nothing to
ensure that Clang cannot optimise away the space[] array that is used to
give different frame sizes to the different test functions. Without
these, Clang 5 optimises out this array and that causes all the unwind
tests to fail.
--HG--
extra : rebase_source : 9d91ea9b08e6771facf7a788163d67f1871f5948
Adds minimal support for reading DWARF CFI pertaining to version 4 of the
standard. Dwarf 4 CFI appears to have become the default used by Clang
version 5. There are two changes:
* Accepts cie->version == 4.
* For version 4 CIEs, skips over the two new fields address_size and
segment_size, but ensures that segment_size is zero. Adds comments in
ReadFDEFields about what to do if we ever find a case where segment_size
is nonzero.
This is in no way full or complete Dwarf 4 support, but it is enough to get
LUL working again with Clang 5 compiled code.
--HG--
extra : rebase_source : f4e21ae5b8d0f219a360d14cc242b2aa812056a0
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
Most cases where the pointer is stored into an already-declared variable can
trivially be changed to MakeNotNull<T*>, as the NotNull raw pointer will end
up in a smart pointer.
In RAII cases, the target type can be specified (e.g.:
`MakeNotNull<RefPtr<imgFrame>>)`), in which case the variable type may just be
`auto`, similar to the common use of MakeUnique.
Except when the target type is a base pointer, in which case it must be
specified in the declaration.
MozReview-Commit-ID: BYaSsvMhiDi
--HG--
extra : rebase_source : 8fe6f2aeaff5f515b7af2276c439004fa3a1f3ab
