A feature for testing the optimal placement of the function which
inserts the no-op on free implementation of the allocator dispatch.
The parameters include insertion of the new layer before the
ShutdownThreads() function is called, when it is called, after
it is called, as well as a default disabled state.
Bug: 1266349
Change-Id: I0ada0d28b9ba408dda5715fc3646dc5eae517f5d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5256537
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Takashi Sakamoto <tasak@google.com>
Commit-Queue: Ada Romanowski <adarom@google.com>
Cr-Commit-Position: refs/heads/main@{#1260896}
This also moves the leak check into BrowserMainLoop::PreShutdown
on all platforms. BrowserMainRunnerImpl::Shutdown is the only
caller so there should be no functional change, but it makes it
more ergonomic for the autorelease pool change since the main
loop owns it.
Bug: 1320449
Change-Id: I0de5b22ca4e417bb27cb53e9869e6ab5b1c5f9c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3968740
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1062412}
This change makes the MF Utility Process DPI Aware by calling
EnableHighDPISupport in UtilityMain.
This is needed to allow the Media Foundation Media Engine to correctly
identify the monitor where the Direct Composition surface for the
content will be presented. In the case of SW DRM this is required to
set OPM properties on the monitor. For HW DRM this is required to allow
proper querying of HW properties of the target monitor. Failures here
could result in no video output.
Additionally, as a refactor to move responsibility out of the embedder
this change moves the existing EnableHighDPISupport calls in
chrome_exe_main_win.cc into the respective GpuMain &
BrowserMainRunnerImpl for the GPU & Browser processes.
A sample setup where the MF Utility Process may be required to be DPI
aware (SW DRM) would be a 4K monitor @ 150% DPI scaling & another 1080P
monitor @ 150% positioned below that monitor. Without DPI awareness if
the DComp surface being presented to is on the secondary monitor the
Media Engine would calculate the primary monitor's virtual coordinates
as 3840 x 2160 at 0,0 and the secondary monitor as 1920 x 1080 at 0,
2160. In reality the virtual coordinates of the primary monitor would
be 2560 x 1440 at 0,0 so we'd expect the secondary monitor at 1280 x
720 at 0, 1440. When the engine is given the target DComp surface at
1280 x 720 at 0, 1440 it will end up identifying this as within the
primary monitor's region (since it calculates that region as 3840 x
2160 which will completely enclose 0, 1440, 1280, 2160). As a result
the primary monitor will be marked with any properties required for the
DRM engine's presentation.
A couple of blink web tests (virtual/scalefactor*/fast/hidpi) ended up
needing re-baselining. This appears to be a result of moving the
EnableHighDPISupport for Browser out of wWinMain in chrome_exe_main_win
and into BrowserMainRunnerImpl::Initialize. When content shell is
running BrowserMainRunnerImpl::Initialize will be called (in turn
enabling High DPI Support) however the previous wWinMain code was not
called with an empty process Id, thus it was not calling
EnableHighDPISupport. As a result in this change in calling
EnableHighDPISupport there were some minor discrepancies in OS UX, like
scroll bars, for some of the expected images.
Bug: 1369598
Change-Id: Ia64173cea960da9bdf23aad878cb199f44a4363a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3898640
Auto-Submit: William Carr <wicarr@microsoft.com>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/main@{#1057058}
This needs to happen before any child processes are launched on
the launcher thread, because otherwise the launches might use
the incorrect child binary, causing version mismatch.
TEST=manual, see bug.
BUG=1314491
Change-Id: I4c07be06aeddaa0ae2bd3fc9e6d990a6346db2ad
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3591579
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#994412}
The platform may fail to initialise, but currently there is no way to
shutdown gracefully, instead platforms have to CHECK or LOG(FATAL),
which essentially crashes the browser. This seems unnecessary because
harmless things like launching chrome with a wrong platform cause
crashes that are then reported to Crashpad.
This patch introduces the early failure path for the platforms: they can
do primary checks at the stage of initialising the UI, and return
whether they succedeed. In case of failure, the process exits with
normal status.
Bug: 1280138
Change-Id: I176be3ba914cbdb2544478de5228476dcb3ccd21
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3351790
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Alexander Dunaev <adunaev@igalia.com>
Cr-Commit-Position: refs/heads/main@{#961077}
This is taking care of a long-standing TODO to move these OnceClosure
holders rather than copy them around with their OnceClosure* members.
This is a precursor to
https://chromium-review.googlesource.com/c/chromium/src/+/3187153/35#message-fcc92e9f85e73f0e5ba6c03610a95cda8736f1f9
which highlighted a problem where some tests see a non-null
MainFunctionParams::ui_task but running the closure results in a UAF.
Logs show that the test hitting the UAF is not the one setting this
field. This CL makes that impossible and fixes the issue in the
follow-up CL.
This CL is intended to be a logical no-op.
This CL touches a lot of files and must happen all at once.
The core change is that ContentMainParams and MainFunctionParams's
moveable fields (ui_task, created_main_parts_closure, and startup_data)
are now held by moveable types rather than raw pointers.
This trickles in the following chain:
main() (in various *_main.cc)
(or SetUp() in !OS_ANDROID browser_test_base.cc)
-> ContentMain()
-> ContentMainRunnerImpl::Initialize()
(forwards arg into MainFunctionParams)
-> RunBrowser()
-> BrowserMain()
-> BrowserMainRunnerImpl::Initialize()
-> BrowserMainLoop (stores MainFunctionParams)
-> BrowserMainLoop::Init
-> ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)BrowserMainParts(Platform)
-> (Embedder)BrowserMainParts
-> RunOtherNamedProcessTypeMain()
-> (Embedder)ContentMainDelegate::RunProcess()
(or)
-> FooMain() (kMainFunctions)
(or)
-> RunZygote()
(creates its own MainFunctionParams)
-> (Embedder)ContentMainDelegate::RunProcess()
(on OS_ANDROID, browser_test_base.cc calls directly into
ContentMainDelegate::RunProcess())
Few of these needed the params after passing them down so a move-only
model was simple to adapt (even if invasive). The few exceptions like
BrowserMainRunnerImpl::Initialize consuming |created_main_parts_closure|
are better off in the new model (where they take the OnceClosure before
passing down the params) because that prevents others down the chain
from having access to a OnceClosure they shouldn't invoke anyways.
Noteworthy:
- ContentMainDelegate::RunProcess():
Returned an exit_code >= 0 to indicate the embedder elected to handle
the run request given these params. With move-only semantics it is
necessary to return the params back when the embedder declines
handling this run request. An absl::variant return value is used
to satisfy this requirement.
- content/public/test/test_launcher.h : GetContentMainParams():
Becomes CopyContentMainParams() and only exposes a copy of copyable
params. Uses new ContentMainParams::ShallowCopyForTesting() which
verifies that moveable fields are still null by that time as should be
the case in the order browser tests are initialized.
- MainFunctionParams::command_line being const& violated the style-guide
rule to "avoid defining functions that require a const reference
parameter to outlive the call". This also prevented moving. The type
was hence switched to a const CommandLine*.
- BUILD.gn changes for nacl_helper_win_64 which requires static linking
of its minimal //content deps (was previously missing a dep but was
getting away with it because MainFunctionParams was .h only; required
now with .cc). This was already done for static_switches and this CL
adds static_main_function_params, reusing a similar static_features
target that already existed but was no longer required in
/c/nacl/broker, cleaning that up by replacing rather than copying that
target's definition in this CL.
- ContentMainParams::minimal_browser_mode was weirdly passed as a
parameter to ContentMainRunner::Run(bool start_minimal_browser) but
that method also has access to the ContentMainParams originally passed
via ContentMainRunner::Init(). Passing the param again from Run()
would be a use-after-move in content_main.cc, instead
content_main_runner_impl.cc was updated to use the param it already
has in store.
Bug: 1175074
Change-Id: I3af90505525e426383c59107a3903d645d455682
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244976
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Owners-Override: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940478}
@QA: This CL is a no-op.
The meaning of this phase has diverged and become increasingly
confusing over the years.
This is not the timing at which the main message loop starts but rather
this is where it is created.
The previous term is easily confused with things like
VariationsService::PerformPreMainMessageLoopStartup
startup_metric_utils::RecordBrowserMainMessageLoopStart
that actually represent when the message loop starts.
This confusion has led to new calls being associated with the wrong
phase, e.g.
https://chromium-review.googlesource.com/c/chromium/src/+/2685139/6#message-d1f863178a7982698d1ff5a032b79e33e9e1d5ce
Bug: 1175074
Change-Id: I0535042abe69431501c9b3da3cfb2eae445fde0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2892278
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Owners-Override: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#883468}
Refactor BrowserMainParts so that BrowserMainLoop owns the loop and
only gives embedders the opportunity to configure it before it runs it.
This is intended to be a no-op logic wise but will be key in a follow-up
change where the loop will be run in multiple steps (until "first idle"
and then forever with a new BrowserMainParts::OnFirstIdle() phase in
between):
https://chromium-review.googlesource.com/c/chromium/src/+/2678899
It was previously strange to have all phases managed by BrowserMainLoop
(BrowserMainParts is only for Pre/Post); *except* for actually running
the loop.
The key changes are in browser_main_loop.cc and in browser_main_parts.h
where this CL introduces WillRunMainMessageLoop() as a replacement for
an overridable MainMessageLoopRun(). Everything else is a side-effect of
that change (intended to be a no-op).
WillRunMainMessageLoop() was necessary instead of augmenting
PreMainMessageLoopRun() because the latter is part of
CreateStartupTasks() and unintuitively runs in a separate phase of
startup which is not guaranteed to be immediately before
MainMessageLoopRun()...
PreMainMessageLoopRun() was modified slightly to return the |error_code|
like many of its sibling methods already did (this was previously an
out-param on MainMessageLoopRun() but no overrides modified the value
after PreMainMessageLoopRun()).
Also took advantage of this CL to further document each phase's role.
Bug: 1175074
Change-Id: I44f84781340fe15efdeac73c7ac35367b1c216f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2725153
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#863314}
Refactor startup tracing logic out of TracingControllerImpl and use
modern TracingSession from Perfetto client API directly.
This allows for much greater simplification, including removing
substantial amount of logic from TracingControllerImpl (including
logic for finishing trace recording after a timeout) and removing
PerfettoFileTracer.
This also allows for a clean implementation of features like streaming
trace to a file and merging browsertest and startup tracing logic.
R=eseckler@chromium.org,skyostil@chromium.org
BUG=1157954,1082916
Change-Id: Id4c608b05cbd6b0696cb8e3445888b6a9d86c797
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2587040
Commit-Queue: Alexander Timin <altimin@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#839190}
CHECK, CHECK_EQ etc., and NOTREACHED/NOTIMPLEMENTED have moved
to the much smaller headers check.h, check_op.h, and notreached.h,
respectively.
This CL updates .cc files to use those headers instead when
possible, with the purpose of saving compile time.
(Split out from https://crrev.com/c/2164525 which also has
notes on how the change was generated.)
Bug: 1031540
Change-Id: I643818242b92e19a1048fac89dd8aae323e8b1ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2164510
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#763511}
Basically ran
sed -i '/base\/message_loop\/message_loop.h/d'
for a bunch of files that no longer use MessageLoop. Came up with the
file list by a combination of greps and trial and error compiles. It is
still possible, but unlikely, that I had false positives but due to
transitive dependencies the compiles succeed. Given that we will
eventually get rid of message_loop.h entirely this should be fine.
If any of the optional try jobs fails to build please consider just
adding #include "base/message_loop/message_loop.h"
to the files that fail to build instead of reverting the entire patch.
This patch will be reviewed according to
https: //chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#mechanical-changes
TBR=gab@chromium.org
Bug: 891670
Change-Id: If56ad40631b3ce02931149cb754131c6a021d899
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1829080
Reviewed-by: Carlos Caballero <carlscab@google.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Carlos Caballero <carlscab@google.com>
Cr-Commit-Position: refs/heads/master@{#708563}
This CL is proposing to lift the call to FcInit to ensures the
font-config is initialized.
Currently, the FcInit(...) is lazily called on first use. On windows,
the DWrite is early initialized to avoid the lazy initialisation. We
proposed to do the same on Linux.
The behavior should be the same on Windows. On Linux, FcInit should
be called on startup, as we need fonts for any rendering.
The main goal of this change is to help collapsing the bugs / crashes
stack to point to a single culprit. Currently, they are spread over
multiple stackframes in incorrectly reporter.
Memory leak with FcInit(...) - crbug/1000881, crbug/977249
Iterator corrupt, initialisation - crbug/1004254
More signatures are available here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1004254#c11
Change-Id: I1f6d80c790829b1d9416b773d5c9cdba16f90eef
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1808447
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Robert Liao <robliao@chromium.org>
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#699990}
In order to leave the base::ThreadPool symbol available for
an upcoming "destination" task trait.
Also moved ThreadPoolImpl to be the implementation of TaskExecutor,
not ThreadPoolInstance. It was a mistake that base::ThreadPool was
implementing TaskExecutor, its users shouldn't have access to
PostTask*() and Create*TaskRunner*().
TBR=fdoray@chromium.org
(bypass owners for side-effects beyond //base)
Bug: 968047
Change-Id: I0607fba6d7f30d202bf7f61a9f461b1256e87467
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1634851
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#664300}
TracingController may not actually have been initialized if shutdown
occurs very early (before mojo was initialized). In that case, we
shouldn't attempt to finalize startup tracing.
Bug: 961594
Change-Id: I2f913630309cf01598060ad9e1334345603d0fbf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1625108
Auto-Submit: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#662232}
Reason: with the advent of other scheduling primitives in //base
(i.e. SequenceManager), TaskScheduler was no longer the only component
responsible for scheduling tasks. We will from now on refer to the
whole of //base/task as the "task scheduling infrastructure".
There are other types named "TaskScheduler" outside of base:: so
s/TaskScheduler/ThreadPool/ across the codebase wasn't possible.
Instead, this CL did:
1) base/task/task_scheduler => base/task/thread_pool
(catches all files with includes)
1.1) Careful manual search to add files without includes
(e.g. missing IWYU, docs, etc.)
2) TaskScheduler => ThreadPool in all files affected by (1)
3) task_scheduler => thread_pool in all files affected by (1)
4) "task scheduler" => "thread pool" in all files affected by (1)
4) Move task_scheduler_util like headers in
//content //components and //ios
Also:
* Renamed UMA metrics from TaskScheduler.* to ThreadPool.*
and dropped "Pool" from worker pool name suffixes.
* Renamed TaskScheduler*Worker thread names to ThreadPool*Worker
* In base/android: NativeTaskScheduler => NativeScheduler as it
was referring to the whole of base/task.
TaskSchedulerTest.java => NativePostTaskTest.java (former DNE)
* Intentionally ignoring IWYU violations in this already too large
CL.
In follow-up:
* Rename other types as well:
SchedulerWorker => WorkerThread
SchedulerWorkerPool* => WorkerThreadGroup*
Bug: 951388
Change-Id: I5bc2688b593c7682ef7e56d6b228539970ba107e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1561552
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#650997}
Perfetto currently doesn't support tracing during browser shutdown,
because the trace buffer is lost when the tracing service disappears.
AFAICT, there aren't any users of --trace-shutdown, so let's attempt to
kill it.
Bug: 944107
Change-Id: If20c8fea74d179d33df6a98e4480fff001316951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1564124
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#650818}
This is a reland of 399f00ea53.
Addresses test failures of crbug.com/948875 by ensuring that the
PerfettoTracingSession waits until startup tracing is fully enabled
before attempting to disable it again.
Original change's description:
> devtools/tracing: Support perfetto backend + proto output.
>
> Adds the ability for TracingHandler to use the new Perfetto Consumer
> interface to control a tracing session. For now, we still support the
> old TracingController backend via a new TracingSession virtual class.
>
> Also adds a proto output format option to the protocol.
> Further adds necessary missing methods to the perfetto ConsumerHost
> interface.
>
> To support startup tracing with perfetto + retrieving of the trace via
> DevTools, TracingHandler needs to become the consumer that initiates
> and controls the startup session, instead of TracingController.
> Otherwise, the trace data can't be read via DevTools. For this, we add a
> new command line flag.
>
> Background: We're replacing the old tracing backend (TracingController +
> TraceLog) with Perfetto! In this process, former clients of
> TracingController become consumers of the Perfetto service instead.
>
> Bug: 925142, 938879
> Change-Id: I2ac389e4b9a6d258b784acaf76043417be4f4f3b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1505934
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Juan Antonio Navarro Pérez <perezju@chromium.org>
> Reviewed-by: oysteine <oysteine@chromium.org>
> Commit-Queue: Eric Seckler <eseckler@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#646895}
Bug: 925142, 938879, 948875
TBR: dgozman@chromium.org,dcheng@chromium.org,perezju@chromium.org
Change-Id: Ie80d261b9940b2de1917729736f6bb116290302d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1553594
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#648280}
Break up //ui/base/ime into several components, one for each
implementation, plus a factory component.
The reason this is useful is that it provides a cycle-free way for ozone
to choose which ui::InputMethod implementation to use. Each InputMethod
implementation creates a natural component that platforms can depend on
if they use that InputMethod. The factory component is layered above
these to provide a single entry point for creating the implementation.
This introduces some more fine grained dependencies:
- Targets that directly use a particular ui::InputMethod implementation
now have to declare an explicit dependency on its component
- Targets that need to create an appropriate ui::InputMethod without
knowing which one they want need to declare a dependency on the factory
component.
Targets that just use the ui::InputMethod base class and related
interfaces can continue to depend on //ui/base/ime.
Bug: 943789
Test: various builds, ui_unittests
TBR=sky@chromium.org
(mechanical BUILD & include changes)
Change-Id: I83ef7b3112e2e68cada86b7ce1aa598a20f3c7cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1531479
Reviewed-by: Shu Chen <shuchen@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#647403}
This reverts commit 399f00ea53.
Reason for revert: crbug.com/948875
Original change's description:
> devtools/tracing: Support perfetto backend + proto output.
>
> Adds the ability for TracingHandler to use the new Perfetto Consumer
> interface to control a tracing session. For now, we still support the
> old TracingController backend via a new TracingSession virtual class.
>
> Also adds a proto output format option to the protocol.
> Further adds necessary missing methods to the perfetto ConsumerHost
> interface.
>
> To support startup tracing with perfetto + retrieving of the trace via
> DevTools, TracingHandler needs to become the consumer that initiates
> and controls the startup session, instead of TracingController.
> Otherwise, the trace data can't be read via DevTools. For this, we add a
> new command line flag.
>
> Background: We're replacing the old tracing backend (TracingController +
> TraceLog) with Perfetto! In this process, former clients of
> TracingController become consumers of the Perfetto service instead.
>
> Bug: 925142, 938879
> Change-Id: I2ac389e4b9a6d258b784acaf76043417be4f4f3b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1505934
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Juan Antonio Navarro Pérez <perezju@chromium.org>
> Reviewed-by: oysteine <oysteine@chromium.org>
> Commit-Queue: Eric Seckler <eseckler@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#646895}
TBR=dgozman@chromium.org,dcheng@chromium.org,alph@chromium.org,oysteine@chromium.org,perezju@chromium.org,eseckler@chromium.org
Change-Id: I52fa78ed3bdd659f42708de288d1ba85d54d7e12
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 925142, 938879, 948875
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1549880
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646969}
Adds the ability for TracingHandler to use the new Perfetto Consumer
interface to control a tracing session. For now, we still support the
old TracingController backend via a new TracingSession virtual class.
Also adds a proto output format option to the protocol.
Further adds necessary missing methods to the perfetto ConsumerHost
interface.
To support startup tracing with perfetto + retrieving of the trace via
DevTools, TracingHandler needs to become the consumer that initiates
and controls the startup session, instead of TracingController.
Otherwise, the trace data can't be read via DevTools. For this, we add a
new command line flag.
Background: We're replacing the old tracing backend (TracingController +
TraceLog) with Perfetto! In this process, former clients of
TracingController become consumers of the Perfetto service instead.
Bug: 925142, 938879
Change-Id: I2ac389e4b9a6d258b784acaf76043417be4f4f3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1505934
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Juan Antonio Navarro Pérez <perezju@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646895}
As a final step, replace all includes back:
- mv message_loop_current.h message_loop.h
- s/message_loop_forward.h/message_loop.h/ in all includes.
- s/message_loop_forward.h/message_loop.h/ in base/BUILD.gn
- Remove message_loop_forward.h from third_party/DEPS.
TBR=gab@chromium.orgR=gab@chromium.org
BUG=891670
Change-Id: I623077025701459ddb7045cbcfdad138aa90a9e4
Reviewed-on: https://chromium-review.googlesource.com/c/1313110
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604690}
To facilitate splitting MessageLoop into MessageLoop and MessageLoopImpl
introduce message_loop_forward.h and use it everywhere.
- s/message_loop.h/message_loop_forward.h/ in all includes.
- Add message_loop_forward.h to base/BUILD.gn.
- Add message_loop_forward.h to third_party/DEPS.
TBR=gab@chromium.org
BUG=891670
Change-Id: Ibac3a24f5bd4291c9d57dd32c627477e4e6ef324
Reviewed-on: https://chromium-review.googlesource.com/c/1313108
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604672}
This is a follow up CL for: https://crrev.com/c/1115783.
In this CL, we use ScopedExecutionFence to prevents tasks running between the
peorid from BrowserMainRunner is instantiated to
BrowserMainLoop::CreateThreads() is called.
Bug: 846846
Change-Id: I9dec8415e45f901c5883c196ab867c0ea4928594
Reviewed-on: https://chromium-review.googlesource.com/c/1174955
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597255}
Make Poisson sampler a separate class that is responsible for listening
for allocation and doing the sampling with given sampling interval.
SamplingHeapProfiler is now an observer of PoissonAllocationObserver.
Once a sample added it record the native stack and stores the sample
in the map. The list of recorded samples can then be retrieved by clients.
TBR=ajwong@chromium.org
BUG=803276
Change-Id: I1e568b9839d9cc0099704ba1b9f047c14a46a0ee
Reviewed-on: https://chromium-review.googlesource.com/1189713
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586369}
The startup category in background tracing is not useful to trigger with
a histogram since it has to start early at startup for getting useful
information.
The startup category will set a flag in app preferences and start
tracing next time chrome starts and upload a report. We can keep having
session consistency for the trials, with startup traces being uploaded
one session after the config was seen.
BUG=859260
Change-Id: I588cb5ebd21e96abe9230718f69775d271f827f5
Reviewed-on: https://chromium-review.googlesource.com/1155996
Commit-Queue: Siddhartha S <ssid@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584303}
The service manager thread and (TODO) ServiceManager might be created
before the full browser starts, and we want to reuse them when starting
the full browser. Therefore, we add a pointer of BrowserStartupData in
MainFunctionParams.
Particularly, in this CL, ContentMainRunnerImpl creates and owns a
BrowserStartupData object. It passes a pointer of the BrowserStartupData
through the main function parameter to BrowserMainLoop.
The BrowserStartupData interface was introduced in:
https://crrev.com/c/1117471.
Bug: 846846, 853308
Change-Id: Ie11063227a670cd8d72935131e854ee2b5c46e4e
Reviewed-on: https://chromium-review.googlesource.com/1108178
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574054}
This is a reland of I23ef57eb52bfb1eb363682dadf98c571c12afcd1.
It was reverted in Ia548067acbf640010f4c8fbed29a0012a274af05. Reason for revert:
Findit (https://goo.gl/kROfz5) identified this CL at revision 557680 as the culprit
for introducing flakiness in the tests as shown on:
https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vZmM5NTUwMWZiMjllM2U3NDg3ZmZmOThjMTdlNmFhYmExMDQ2YjMzMAw
The data race has been fixed in:
https://chromium-review.googlesource.com/c/chromium/src/+/1064450.
Original change's description:
> Create BrowserThread::IO thread before browser main loop to start
> ServiceManager.
>
> We need a thread to post/execute tasks when starting the
> ServiceManager. This thread needs to be created before the browser
> main loop is initialized, and will be registered as the
> BrowserThread::IO thread which is currently used by ServiceManager
> connections.
>
> The creation of such a thread is moved to service_manager::main via
> MainDelegate::CreateIOThreadAndGetTaskRunner(). Since it requires no
> thread created before calling fork() on posix, we also move the setup
> of sandbox before creating the IO thread.
>
> Bug: 740677, 729596
> Change-Id: I23ef57eb52bfb1eb363682dadf98c571c12afcd1
> Reviewed-on: https://chromium-review.googlesource.com/969098
> Commit-Queue: Xi Han <hanxi@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#557680}
Bug: 740677, 729596
Change-Id: I9afb0cdc0f11a1d437c2e9bd09c374503c3d5a4b
Reviewed-on: https://chromium-review.googlesource.com/1059949
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560724}
ServiceManager.
We need a thread to post/execute tasks when starting the
ServiceManager. This thread needs to be created before the browser
main loop is initialized, and will be registered as the
BrowserThread::IO thread which is currently used by ServiceManager
connections.
The creation of such a thread is moved to service_manager::main via
MainDelegate::CreateIOThreadAndGetTaskRunner(). Since it requires no
thread created before calling fork() on posix, we also move the setup
of sandbox before creating the IO thread.
Bug: 740677, 729596
Change-Id: I23ef57eb52bfb1eb363682dadf98c571c12afcd1
Reviewed-on: https://chromium-review.googlesource.com/969098
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557680}
This CL is a precursor CL for https://crrev.com/c/969098. It simply contains a
file renaming to keep log history:
1. content_main_runner.cc rename to content_main_runner_impl.cc
2. browser_main_runner.cc rename to browser_main_runner_impl.cc
It allows to introduce content_main_runner_impl.h and browser_main_runner_impl.h
which contain new methods without changing their interface in /content/public.
Bug: 740677
Change-Id: I4e42bb594d65888b4358ac843b13837be26a5b7e
Reviewed-on: https://chromium-review.googlesource.com/1042456
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557620}
