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
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 overlay elements with children of editMenuOverlay.xul are moved into
include files (editMenuCommands.inc.xul and editMenuKeys.inc.xul). For
the other single elements in the overlay, the attributes are inlined
wherever they are used.
MozReview-Commit-ID: 792cuzUvQxT
--HG--
extra : rebase_source : 58e4c05bde16cee873d37c6198de102d048499c2
As of Bug 1425463 it's available in all contexts (including JSM). The following
patche is going to remove imports to Console.jsm, so prepare for this by allowing
it to be used as a global in eslint.
MozReview-Commit-ID: 3gCIspnlVgB
--HG--
extra : rebase_source : 6da75d42d7d937b628ef1d9c0d4e349fd76eda36
