Removes unused gonk code
Changes use of Array.prototype.indexOf(val) != -1 to Array.prototype.includes(val)
Some very minor indentation and logging cleanup
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
The primary patch in bug 1308876 causes frames to be reflowed less often
with NS_FRAME_IS_DIRTY, particularly when multiple passes of reflow are
required for the frame or one of its ancestors (which is generally the
case for a document that ends up not having scrollbars). This change
causes this assert to fire on various SVG tests such as
layout/reftests/svg/svg-integration/conditions-outer-svg-01.xhtml .
This happens because the outer SVG with conditional processing (in this
test, systemLanguage="x") is reflowed due to its parent resizing,
without NS_FRAME_IS_DIRTY set. This is a relatively normal thing to
happen during reflow; we just didn't have any tests that exercise it.
This patch adds a crashtest that triggers the assertion through the same
mechanism, but with a dynamic change, rather than depending on the
non-dirty reflow triggered by bug 1308876. (I confirmed locally that
this test does trigger the assertion without this patch, when run in the
crashtest harness.)
I think fundamentally the assertion isn't valid, and we should instead
be testing the condition that it asserts.
MozReview-Commit-ID: D8hjAbjKyuL
--HG--
extra : transplant_source : %98C%3A%B1%93jb%E7%3D%81%19%97%A6%04%0F%88%8B%D2%A35
The lifetime of async IPDL returned promise may be longer than its actor.
That is, the handler (receiver) may have not resolve/reject the promise when the actor
is destroyed. In this case, we have to reject all the pending promises before
ActorDestroy() is called on the "sender" side.
Besides, the handler (receiver) can reject with reason "ActorDestroyed" to silently
cancel the promise without trying to reply to the remote actor which may
have died. The sender-side promise is responsible for rejecting the pending promises,
which will be done in MessageChannel::RejectPendingPromisesForActor().
MozReview-Commit-ID: 4XjmquZzDBO
--HG--
extra : rebase_source : 48539e35e4587e09be1d66497b1ea32d1a95ee9a
Functions like BuildDisplayListForStackingContext or BuildDisplayListForChild look
up EffectSet property several times in callees, such as IsTransformed() or
HasOpacity(), which is time wasting.
We should look up EffectSet just once, and pass the found one to all callees
that need it.
MozReview-Commit-ID: GZywm2UcpU7
--HG--
extra : rebase_source : 21f5dd0076a90d876a6df35eee2b886844b44f0a
FRAME_STATE_BIT of nsFrame and nsINode::mBoolFlags are both full, we need to
find another place to hold MAY_HAVE_OPACITY information.
nsINode::mSlots might be a choice, but since we always use this information in
painting, memory footprint of nsINode will become larger after this change.
So I decide to put this information right in EffectSet. The drawback of storing
this information in EffectSet is, although unnecessary Effect look-up is
prevented, we still need EffectSet property look-up in each time
HasOpacityInternal call, so we need Part 2.
Conceptually, Part 1 and Part 2 are independent.
MozReview-Commit-ID: 6sfBFSHjxQb
--HG--
extra : rebase_source : 394141cec3b44bb352297a0add8f9763d815bddb
This prevents short-lived processes when we are not at the maximum normal content process count and the new window's first tab is not going to load in that remote type.
This ensures that we never get a short-lived process for the new tab, which can happen if we are not at the maximum for that remote type.
We also set the correct remoteType.
This change means that any related http pages driven through content (window.open, links, etc.) will continue to be loaded in the file content process.
Same-origin loads via the UI will also remain in the file content process.
Cross-origin loads via the UI will cause a process switch.
History navigation will stay in the process, if it was originally loaded in that process.
This flag is for when we've loaded a URI in a remote type that is not the default
for compatibility reasons (for example related http in the file content process).
So that we can load the history entry in that same process as well.