gecko-dev/docshell/base/timeline
Tom Tromey 5538d692d3 Bug 1286877 - do not set c-basic-offset for python-mode; r=gps
This removes the unnecessary setting of c-basic-offset from all
python-mode files.

This was automatically generated using

    perl -pi -e 's/; *c-basic-offset: *[0-9]+//'

... on the affected files.

The bulk of these files are moz.build files but there a few others as
well.

MozReview-Commit-ID: 2pPf3DEiZqx

--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
2016-07-14 10:16:42 -06:00
..
AbstractTimelineMarker.cpp Bug 1211841 - Style off the main thread markers differently, r=jsantell 2015-10-28 11:00:52 +01:00
AbstractTimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 1 - remove non-useful 'explicit', r=smaug 2016-03-01 09:15:50 +01:00
AutoGlobalTimelineMarker.cpp Bug 1225618 - Do not capture stacks for cycle collection timeline markers; r=vporof 2015-11-23 16:50:56 +01:00
AutoGlobalTimelineMarker.h Bug 1225618 - Do not capture stacks for cycle collection timeline markers; r=vporof 2015-11-23 16:50:56 +01:00
AutoTimelineMarker.cpp Bug 1202657 - Add markers for workers' message passing and serialization/deserialization, r=smaug, jsantell, tromey, ejpbruel 2015-10-21 23:10:05 +02:00
AutoTimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 1 - remove non-useful 'explicit', r=smaug 2016-03-01 09:15:50 +01:00
CompositeTimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 1 - remove non-useful 'explicit', r=smaug 2016-03-01 09:15:50 +01:00
ConsoleTimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 1 - remove non-useful 'explicit', r=smaug 2016-03-01 09:15:50 +01:00
DocLoadingTimelineMarker.h Bug 1218078 - Show onload and DOMContentLoaded markers in the netmonitor's frontend, r=smaug, jsantell, tromey 2015-11-11 23:11:40 +01:00
EventTimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 1 - remove non-useful 'explicit', r=smaug 2016-03-01 09:15:50 +01:00
JavascriptTimelineMarker.h Bug 1248948 - Don't pass non-SavedFrame objects to SavedFrame JSAPI functions; r=tromey r=evilpie 2016-04-05 13:51:00 +02:00
LayerTimelineMarker.h Bug 1239864 (part 3) - Use the new rect iterators in docshell/ and dom/. r=baku. 2016-01-18 17:20:44 -08:00
MarkersStorage.cpp Bug 1202657 - Add markers for workers' message passing and serialization/deserialization, r=smaug, jsantell, tromey, ejpbruel 2015-10-21 23:10:05 +02:00
MarkersStorage.h Bug 1202657 - Add markers for workers' message passing and serialization/deserialization, r=smaug, jsantell, tromey, ejpbruel 2015-10-21 23:10:05 +02:00
MessagePortTimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 2, r=smaug, r=vporof 2016-03-01 09:16:18 +01:00
moz.build Bug 1286877 - do not set c-basic-offset for python-mode; r=gps 2016-07-14 10:16:42 -06:00
ObservedDocShell.cpp Bug 1255459 - Use AutoRestore in ObservedDocShell::PopMarkers. r=smaug 2016-03-10 08:59:00 -05:00
ObservedDocShell.h Bug 1245743 - Don't push new timeline markers while popping markers. r=vporof 2016-03-09 19:19:47 -05:00
readme.md Bug 1217836 - Add a readme file to our timeline backend, r=jsantell 2015-10-24 17:09:15 +02:00
RestyleTimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 1 - remove non-useful 'explicit', r=smaug 2016-03-01 09:15:50 +01:00
TimelineConsumers.cpp Bug 1253516 - Do not acquire a lock that protects data that is not used; r=vporof 2016-03-14 11:44:00 +01:00
TimelineConsumers.h Bug 1244897 - Use TimerlineConsumers in PopProfileTimelineMarkers to ensure that all methods acquire TimelineConsumers Mutex. r=vporof 2016-03-01 19:54:47 +09:00
TimelineMarker.cpp Bug 1211839 - Don't allow off the main thread markers to nest under main thread markers, r=smaug, jsantell 2015-10-24 17:10:22 +02:00
TimelineMarker.h Bug 1249950 - Add Performance Markers for MessagePort - patch 1 - remove non-useful 'explicit', r=smaug 2016-03-01 09:15:50 +01:00
TimelineMarkerEnums.h Bug 1195232 - Stop using TracingMetadata from GeckoProfiler.h, r=tromey 2015-08-31 16:14:14 +02:00
TimestampTimelineMarker.h Bug 1211839 - Don't allow off the main thread markers to nest under main thread markers, r=smaug, jsantell 2015-10-24 17:10:22 +02:00
WorkerTimelineMarker.h Bug 1257032: Make files in dom/workers actually build without unification. r=baku 2016-03-16 11:51:11 -07:00

#Timeline

The files in this directory are concerned with providing the backend platform features required for the developer tools interested in tracking down operations done in Gecko. The mechanism we use to define these operations are markers.

Examples of traced operations include:

  • Style Recalculation
  • Layout
  • Painting
  • JavaScript run-to-completion
  • HTML parsing
  • etc.

The traced operations are displayed in the DevTools Performance tool's timeline.

This is an overview of how everything works and can be extended.

##MarkersStorage A MarkersStorage is an abstract class defining a place where timeline markers may be held. It defines an interface with pure virtual functions to highlight how this storage can be interacted with:

  • AddMarker: adding a marker, from the main thread only
  • AddOTMTMarker: adding a marker off the main thread only
  • ClearMarkers: clearing all accumulated markers (both from the main thread and off it)
  • PopMarkers: popping all accumulated markers (both from the main thread and off it).

Note on why we handle on/off the main thread markers separately: since most of our markers will come from the main thread, we can be a little more efficient and avoid dealing with multithreading scenarios until all the markers are actually cleared or popped in ClearMarkers or PopMarkers. Main thread markers may only be added via AddMarker, while off the main thread markers may only be added via AddOTMTMarker. Clearing and popping markers will yield until all operations involving off the main thread markers finish. When popping, the markers accumulated off the main thread will be moved over. We expect popping to be fairly infrequent (every few hundred milliseconds, currently we schedule this to happen every 200ms).

##ObservedDocShell The only implementation of a MarkersStorage we have right now is an ObservedDocShell.

Instances of ObservedDocShell accumulate markers that are mostly about a particular docshell. At a high level, for example, an ObservedDocshell would be created when a timeline tool is opened on a page. It is reasonable to assume that most operations which are interesting for that particular page happen on the main thread. However certain operations may happen outside of it, yet are interesting for its developers, for which markers can be created as well (e.g. web audio stuff, service workers etc.). It is also reasonable to assume that a docshell may sometimes not be easily accessible from certain parts of the platform code, but for which markers still need to be created.

Therefore, the following scenarios arise:

  • a). creating a marker on the main thread about a particular dochsell

  • b). creating a marker on the main thread without pinpointing to an affected docshell (unlikely, but allowed; in this case such a marker would have to be stored in all currently existing ObservedDocShell instances)

  • c). creating a marker off the main thread about a particular dochsell (impossible; docshells can't be referenced outside the main thread, in which case some other type of identification mechanism needs to be put in place).

  • d). creating a marker off the main thread without pinpointing to a particular docshell (same path as c. here, such a marker would have to be stored in all currently existing ObservedDocShell instances).

An observed docshell (in other words, "a docshell for which a timeline tool was opened") can thus receive both main thread and off the main thread markers.

Cross-process markers are unnecessary at the moment, but tracked in bug 1200120.

##TimelineConsumers A TimelineConsumer is a singleton that facilitates access to ObservedDocShell instances. This is where a docshell can register/unregister itself as being observed via the AddConsumer and RemoveConsumer methods.

All markers may only be stored via this singleton. Certain helper methods are available:

  • Main thread only AddMarkerForDocShell(nsDocShell*, const char*, MarkerTracingType) AddMarkerForDocShell(nsDocShell*, const char*, const TimeStamp&, MarkerTracingType) AddMarkerForDocShell(nsDocShell*, UniquePtr<AbstractTimelineMarker>&&)

  • Any thread AddMarkerForAllObservedDocShells(const char*, MarkerTracingType) AddMarkerForAllObservedDocShells(const char*, const TimeStamp&, MarkerTracingType) AddMarkerForAllObservedDocShells(UniquePtr<AbstractTimelineMarker>&)

The "main thread only" methods deal with point a). described above. The "any thread" methods deal with points b). and d).

##AbstractTimelineMarker

All markers inherit from this abstract class, providing a simple thread-safe extendable blueprint.

Markers are readonly after instantiation, and will always be identified by a name, a timestamp and their tracing type (START, END, TIMESTAMP). It should not make sense to modify their data after their creation.

There are only two accessible constructors: AbstractTimelineMarker(const char*, MarkerTracingType) AbstractTimelineMarker(const char*, const TimeStamp&, MarkerTracingType) which create a marker with a name and a tracing type. If unspecified, the corresponding timestamp will be the current instantiation time. Instantiating a marker much later after a particular operation is possible, but be careful providing the correct timestamp.

The AddDetails virtual method should be implemented by subclasses when creating WebIDL versions of these markers, which will be sent over to a JavaScript frontend.

##TimelineMarker A TimelineMarker is the main AbstractTimelineMarker implementation. They allow attaching a JavaScript stack on START and TIMESTAMP markers.

These markers will be created when using the TimelineConsumers helper methods which take in a string, a tracing type and (optionally) a timestamp. For more complex markers, subclasses are encouraged. See EventTimelineMarker or ConsoleTimelineMarker for some examples.

##RAII

mozilla::AutoTimelineMarker

The easiest way to trace Gecko events/tasks with start and end timeline markers is to use the mozilla::AutoTimelineMarker RAII class. It automatically adds the start marker on construction, and adds the end marker on destruction. Don't worry too much about potential performance impact! It only actually adds the markers when the given docshell is being observed by a timeline consumer, so essentially nothing will happen if a tool to inspect those markers isn't specifically open.

This class may only be used on the main thread, and pointer to a docshell is necessary. If the docshell is a nullptr, nothing happens and this operation fails silently.

Example: AutoTimelineMarker marker(aTargetNode->OwnerDoc()->GetDocShell(), "Parse HTML");

mozilla::AutoGlobalTimelineMarker`

Similar to the previous RAII class, but doesn't expect a specific docshell, and the marker will be visible in all timeline consumers. This is useful for generic operations that don't involve a particular dochsell, or where a docshell isn't accessible. May also only be used on the main thread.

Example: AutoGlobalTimelineMarker marker("Some global operation");