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}
