This changes the about memory parser to only perform prefix matches if the
path ends in a '/'. For example:
> parse_about_memory.py memory-report.json.gz 'resident'
Will match the 'resident' node, but not 'resident-unique'.
MozReview-Commit-ID: CK2jAemGNDn
The intermittent failure appears to have been due to mOriginsHavingData
only being updated when the db thread flushes. The db thread has a
hard-coded 5 second flush interval. It's likely that e10s startup was
previously so slow that we were assured of having a flush happen by the
time our fresh process created its parent actor.
We correct this by reliably ensuring a flush before spinning up the
process to check preload state. We also ensure a flush at the start of
the test for our check that there was no preload in the initial cases.
We were actually more vulnerable in that case, I believe, but as a
browser chrome test, there were no other tests that would have used
content localStorage.
We additionally ensure that the content process has received and
populated mOriginsHavingData by having the tab opening process wait for
about:blank to load in the process before actually opening our origin.
Prior to this change we were depending on orderings that aren't
guaranteed.
--HG--
extra : rebase_source : 92d3c675cee82ffe8b562e83860601e0c6dc1a9b
Bug 1345990 introduced a "forceNewProcess" argument in
BrowserTestUtils.openNewForegroundTab. By switching to this we can
stop bloating the process count pref to try and produce equivalent
results. To minimize test churn and because it doesn't really hurt to
double-check, the code that asserts that our tabs are each in different
processes and related book-keeping infrastructure have been left intact.
We also set a preference to disable preallocated processes in the interest
of maximizing test consistency and minimizing breakage. It's conceivable
that a preallocated process might end up creating its StorageDBParent
actor prior to when we want, breaking things. By ensuring the process
isn't created until we want it, we avoid a lot of brittleness.
--HG--
extra : rebase_source : 5736f7b2d06b720cefbe82eb6052e71b9fc14f23
This opcode has been blocked on other missing opcodes for a long
time and requires further testing before it is unblocked again.
MozReview-Commit-ID: 7oKkJwxjVu5
This patch uses the profiler_suspend_sample_thread method which was added in
part 1.
With this patch, we no longer manually run code to pause the target thread,
instead using the profiler's provided code to do so. In addition, we no longer
manually walk the stack to collect native stack frames, instead relying on the
profiler's cross-platform stack walking logic.
This helps remove some of the code from ThreadStackHelper which was redundant
with the profiler. Much of the pseudostack code in ThreadStackHelper is also
redundant, and should hopefully be eliminated in a follow-up.
MozReview-Commit-ID: 4RjLHt6inH9
This patch performs a refactoring to the internals of the profiler in order to
expose a function, profiler_suspend_and_sample_thread, which can be called from a
background thread to suspend, sample the native stack, and then resume the
target passed-in thread.
The interface was designed to expose as few internals of the profiler as
possible, exposing only a single callback which accepts the list of program
counters and stack pointers collected during the backtrace.
A method `profiler_current_thread_id` was also added to get the thread_id of the
current thread, which can then be passed by another thread into
profiler_suspend_sample_thread to sample the stack of that thread.
This is implemented in two parts:
1) Splitting SamplerThread into two classes: Sampler, and SamplerThread.
Sampler was created to extract the core logic from SamplerThread which manages
unix signals on android and linux, as well as suspends the target thread on all
platforms. SamplerThread was then modified to subclass this type, adding the
extra methods and fields required for the creation and management of the actual
Sampler Thread.
Some work was done to ensure that the methods on Sampler would not require
ActivePS to be present, as we intend to sample threads when the profiler is not
active for the Background Hang Reporter.
2) Moving the Tick() logic into the TickController interface.
A TickController interface was added to platform which has 2 methods: Tick and
Backtrace. The Tick method replaces the previous Tick() static method, allowing
it to be overridden by a different consumer of SuspendAndSampleAndResumeThread,
while the Backtrace() method replaces the previous MergeStacksIntoProfile
method, allowing it to be overridden by different consumers of
DoNativeBacktrace.
This interface object is then used to wrap implementation specific data, such as
the ProfilerBuffer, and is threaded through the SuspendAndSampleAndResumeThread
and DoNativeBacktrace methods.
This change added 2 virtual calls to the SamplerThread's critical section, which
I believe should be a small enough overhead that it will not affect profiling
performance. These virtual calls could be avoided using templating, but I
decided that doing so would be unnecessary.
MozReview-Commit-ID: AT48xb2asgV