Confirmed users
398
edits
TaskTracer: Difference between revisions
/* Labels
(update for changes of tasktracer) |
(/* Labels) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 19: | Line 19: | ||
command in gdb. | command in gdb. | ||
(gdb) call | (gdb) call profiler_save_profile_to_file_async(0.0, "/abs/to/logfile") | ||
(gdb) continue | (gdb) continue | ||
| Line 25: | Line 25: | ||
== Dump log == | == Dump log == | ||
Get [https://bitbucket.org/thinker/tttools tttools] | |||
python dumplog.py /path/to/logfile | python dumplog.py /path/to/logfile | ||
| Line 108: | Line 109: | ||
#endif | #endif | ||
... | ... | ||
#ifdef MOZ_TASK_TRACER | |||
mozilla::tasktracer::AddLabel("Event [%s] ...", str...); | mozilla::tasktracer::AddLabel("Event [%s] ...", str...); | ||
#endif | |||
Javascript adds labels with a special prefix. | Javascript adds labels with a special prefix. | ||
console.log("#tt# Log message"); // #tt# is the prefix. | console.log("#tt# Log message"); // #tt# is the prefix. | ||
For the case of labeling at begin and end of a scope, |AutoScopedLabel| is a helper class to do that. | |||
{ | |||
#ifdef MOZ_TASK_TRACER | |||
AutoScopedLabel label("Event [%s] ...", str...); // label "Begin Event [...]..." | |||
#endif | |||
// do something .... | |||
} // label "End Event [...]..." | |||
The "Begin ..." label would be added when the instance of |AutoScopedLabel| was created. And, "End ..." label would be added when the instance was destroyed. | |||
== DESIGN == | |||
TaskTracer has 5 types of logs in its log files, | |||
DISPATCH, BEGIN, END, VTABLE, and LABEL. | |||
They are used to remember | |||
- what the task created and dispatched a new task to | |||
a target thread, | |||
- the time a task was started to run at the target thread, | |||
- the time a task had done its works, | |||
- the type (vtalbe of the class) of the runnable of a given task, and | |||
- labels that denote what was happened in a task. | |||
=== TASK ID === | |||
Each type of logs has a time stamp to denote when it was happened, and | |||
a task ID to uniquely identify a tasks. To make the running code | |||
knowning which task is running at a thread, the ID of the running task | |||
is stored in the TLS, e.q. thread local storage, when the event loop | |||
of the thread starts to run it. That means when a new task was | |||
created and dispatched, TaskTracer got the task ID of the running task | |||
of current thread from TLS, and denote it as the creator/parent of the | |||
new one. | |||
The IDs of a task and its parent task (from TLS) were recorded in a | |||
DISPATCH log when it was dispatched to correlates a task and its | |||
parent task. | |||
When an IPC message was sent, a new task was created and dispatched at | |||
receiving side to handle the message. TaskTracer stores the task ID | |||
of the sender of a message in its header, and uses that ID as the | |||
parent task ID of the task handling the message at receiving site. | |||
With this, TaskTracer correlates tasks over processes. | |||
=== SOURCE EVENT ID AND TYPE === | |||
Not all tasks are always created by another task. For example, a | |||
mouse event would create and dispatch a task to handle it, but the | |||
mouse event itself is no task. TaskTracer calls mouse events or other | |||
events from the kernel as source events. Every source event has an | |||
unique ID to identify it, and assign a type to identify whether it is | |||
a mouse event, keyboard event, ..., or network event. They are source | |||
event IDs and source event types. | |||
The tasks created by source events have no parent task ID, the value of | |||
its parent task ID is identical to its task ID. With this rule, users | |||
know a task was created for handling a source event if its task ID is | |||
identical to its parent task ID. | |||
Source event ID and type would be stored in TLS of threads. They are | |||
also retrieved from TLS and stored in the new runnable of a new task | |||
when the new task is created/dispatched. When a new task was started | |||
to run, the source event ID and type stored on it will be retrieved | |||
and stored to TLS too. That means source event ID and type would | |||
passing along all tasks created for the source event directly or | |||
indirectly. That means they are also dispatched along IPC messages. | |||
=== VTABLE === | |||
For C++, every virtual class, that means a class having at least one | |||
virtual method, has a vtab to store entry points of its virtual | |||
methods. A VTABLE log contains the address of vtab of the concrete | |||
class of an instance of Runnable (a task). With the address of the | |||
vtab of a task, TaskTracer can get the concrete class name of the task | |||
by symbolicating. People can understand the purpose of a task by its | |||
name. | |||