| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
boundaries.
See https://chromiumcodereview.appspot.com/9702014/ for the original code review. Uploading to a new issue due to an AppEngine error...
BUG=103480
TEST=none (refactoring, no functional change expected)
TBR=jam@chromium.org,jar@chromium.org,eroman@chromium.org,jhawkins@chromium.org,ajwong@chromium.org
Review URL: http://codereview.chromium.org/10077001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@132109 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
TBR=sky@chromium.org,dmazzoni@chromium.org,thestig@chromium.org,joaodasilva@chromium.org,willchan@chromium.org,hclam@chromium.org
Review URL: http://codereview.chromium.org/9703098
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@127256 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a relanding of all the cleanup found in the
original CL, without the hooks to actually monitor the
IPC calls. I'm trying to find out what caused the
ASAN bot failures by landing piecemeal (per discussion
with Joi).
The original CL was:
Support tracking of IPC messages as tasks in profiler
Also started to do more cleanup, including creating
a base/profiler directory, and moving parts of the
over-sized tracked_objects.* into that directory.
r=rtenneti
Review URL: http://codereview.chromium.org/8480014
But this CL is:
TBR=joi
Review URL: http://codereview.chromium.org/8499022
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@109040 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also started to do more cleanup, including creating
a base/profiler directory, and moving parts of the
over-sized tracked_objects.* into that directory.
r=rtenneti
Review URL: http://codereview.chromium.org/8480014
TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8496008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@109004 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
| |
Also started to do more cleanup, including creating
a base/profiler directory, and moving parts of the
over-sized tracked_objects.* into that directory.
r=rtenneti
Review URL: http://codereview.chromium.org/8480014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@108752 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a reland of accumulated patches including CLs
8414036, 8425010, 8425013, 8424013.
It fully enables tracking of objects, as seen in about:tracking
in teh release build.
The problem this had in its initaial landing centered on
Mac instability in base_unittest. We were encountering crash
on exit of the tests, with a stack dump involving pthreads.
r=rtenneti
BUG=101856
Review URL: http://codereview.chromium.org/8429009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@108026 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-land of:
http://codereview.chromium.org/8391019/
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107793
Original landing had trouble with message_loop_x.h, due to header
include ordering. I pulled out the structure that was really needed by
tracked_objects.h into a new file tracked_info.*. This allows tracked_objects
to inlude this tracked_info, but not have to include the message_loop.h
totality. I also removed a DCHECK that that was triggering on a test,
and added yet one more file (browser_main.cc) where I removed a #ifdef
for TRACKING_ALL_OBJECTS. The changes were minor, and I'm hoping to get
clear perf runs with tihs landing, so I'm going to TBR it and reland
early in the morning.
Comments from original landing:
Support is now controlled by the flag:
--enable-tracking
and the default is always on. To turn it off, use:
--enable-tracking=0
All profiler code is compiled now in release and official
builds (in addition to debug, where it was already active),
but most entry points can be disabled (turned into no-ops)
by a single const bool setting atop tracked_objects.cc (in
case folks want to revert the perf-impact of this change).
Transition to faster Now() service on Windows for the
profiler use only.
The TimeTicks::Now() function on Window uses locking
to get a 64 bit time value. This CL transitions
times used for profiling to more directly use a
32 bit Time interface, which is actually what drives the
64 bit TimeTicks. By using the smaller value, we avoid
the need for locks, or even atomic operations for the most
part in the tracking system. On linux, we just down-sample
the standard TimeTicks to 32 bits for consistency (clean
ability to snapshot asyncronously without atomics...
but I should verify that such is helpful to performance).
I've also put in yet more cleanup and refactoring.
tbr=rtenneti
bug=101856
Review URL: http://codereview.chromium.org/8414036
TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8430004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107961 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-land of:
http://codereview.chromium.org/8391019/
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107793
Original landing had trouble with message_loop_x.h, due to header
include ordering. I pulled out the structure that was really needed by
tracked_objects.h into a new file tracked_info.*. This allows tracked_objects
to inlude this tracked_info, but not have to include the message_loop.h
totality. I also removed a DCHECK that that was triggering on a test,
and added yet one more file (browser_main.cc) where I removed a #ifdef
for TRACKING_ALL_OBJECTS. The changes were minor, and I'm hoping to get
clear perf runs with tihs landing, so I'm going to TBR it and reland
early in the morning.
Comments from original landing:
Support is now controlled by the flag:
--enable-tracking
and the default is always on. To turn it off, use:
--enable-tracking=0
All profiler code is compiled now in release and official
builds (in addition to debug, where it was already active),
but most entry points can be disabled (turned into no-ops)
by a single const bool setting atop tracked_objects.cc (in
case folks want to revert the perf-impact of this change).
Transition to faster Now() service on Windows for the
profiler use only.
The TimeTicks::Now() function on Window uses locking
to get a 64 bit time value. This CL transitions
times used for profiling to more directly use a
32 bit Time interface, which is actually what drives the
64 bit TimeTicks. By using the smaller value, we avoid
the need for locks, or even atomic operations for the most
part in the tracking system. On linux, we just down-sample
the standard TimeTicks to 32 bits for consistency (clean
ability to snapshot asyncronously without atomics...
but I should verify that such is helpful to performance).
I've also put in yet more cleanup and refactoring.
tbr=rtenneti
bug=101856
Review URL: http://codereview.chromium.org/8414036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107895 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support is now controlled by the flag:
--enable-tracking
and the default is always on. To turn it off, use:
--enable-tracking=0
All profiler code is compiled now in release and official
builds (in addition to debug, where it was already active),
but most entry points can be disabled (turned into no-ops)
by a single const bool setting atop tracked_objects.cc (in
case folks want to revert the perf-impact of this change).
Transition to faster Now() service on Windows for the
profiler use only.
The TimeTicks::Now() function on Window uses locking
to get a 64 bit time value. This CL transitions
times used for profiling to more directly use a
32 bit Time interface, which is actually what drives the
64 bit TimeTicks. By using the smaller value, we avoid
the need for locks, or even atomic operations for the most
part in the tracking system. On linux, we just down-sample
the standard TimeTicks to 32 bits for consistency (clean
ability to snapshot asyncronously without atomics...
but I should verify that such is helpful to performance).
I've also put in yet more cleanup and refactoring.
r=rtenneti
bug=101856
Review URL: http://codereview.chromium.org/8391019
TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8400073
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107799 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support is now controlled by the flag:
--enable-tracking
and the default is always on. To turn it off, use:
--enable-tracking=0
All profiler code is compiled now in release and official
builds (in addition to debug, where it was already active),
but most entry points can be disabled (turned into no-ops)
by a single const bool setting atop tracked_objects.cc (in
case folks want to revert the perf-impact of this change).
Transition to faster Now() service on Windows for the
profiler use only.
The TimeTicks::Now() function on Window uses locking
to get a 64 bit time value. This CL transitions
times used for profiling to more directly use a
32 bit Time interface, which is actually what drives the
64 bit TimeTicks. By using the smaller value, we avoid
the need for locks, or even atomic operations for the most
part in the tracking system. On linux, we just down-sample
the standard TimeTicks to 32 bits for consistency (clean
ability to snapshot asyncronously without atomics...
but I should verify that such is helpful to performance).
I've also put in yet more cleanup and refactoring.
r=rtenneti
bug=101856
Review URL: http://codereview.chromium.org/8391019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107793 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
| |
I also fought a terrible (but educational) fight with Thread Local Store, and its ability to do cleanup (call destructors) at thread exit (notably applicable to Worker Threads). Thta is why there were soooo many test bot runs and tiny checkins. I now have a plan in mind that won't rely on that functionality. The code seems to work cross-platform, but if I have trouble with Linux, I'll repeatedly leak ThreadData contexts temporarily on that platform. Given that the code is only enabled under Debug, this is not yet a real problem.
Each CL I write for this code also includes a bunch of cleanup. In this case, I changed the Write() methods to WriteHTML(), since I didn't want any confusion with JSON writing etc. I also did a bunch of tiny cleanups which should not have changed what the code does.
r=rtenneti
Review URL: http://codereview.chromium.org/8313013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@106952 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(non-official builds only).
It's very helpful to understand what chrome is doing at runtime. Sometimes a thread in chrome does something expensive that causes a frame hitch. With this change, any expensive task will show up clearly in traces, with the file/function of where the task was posted.
TEST=go to about:tracing, run a trace and notice that all tasks are traced.
Review URL: http://codereview.chromium.org/7778033
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@103740 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
The Birth/Death tracking of tasks has been moved out-of-band into MessageLoop's PendingTask structure.
Thus, Task no longer needs to inherit from Tracked. Since Task was the only child of Tracked, delete the Tracked class and move Location to its own file.
BUG=none
TEST=builds
Review URL: http://codereview.chromium.org/7879006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102132 0039d316-1c4b-4281-b951-d872f2087c98
|
