8b33c87239
Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U A lot has changed since the last patchset! I recommend revisiting this design doc and reading the parts in green. I explain the roadmap for what changes to expect from ETW instrumentation as well as the instrumentation of this particular CL. I'll do my best to answer any further questions anyone has about my particular instrumentation or ETW in general :) --- This is the first of a series of changelists to round out ETW instrumentation for V8. This changelist represents the most minimal change needed to instrument ETW in V8. In particular, it: - defines and registers the ETW provider, - interacts minimally with the rest of V8, by hooking into the existing TracingController::AddTraceEvent function, - is designed with a platform-agnostic layer, so that event tracers for other platforms can be instrumented in teh future. Some notes on instrumentation (aka I copied stuff from the design doc): We make heavy use of the TraceLogging API to log events. It differs from previous methods of emitting ETW events in that it doesn<E2><80><99>t require the overhead of a separate manifest file to keep track of metadata; rather, events using this API are self-descriptive. Here are the five major steps to instrument the TraceLogging API: - Forward declare the provider (from provider-win.h) - Define the provider in a .cc file (from provider-win.cc) - Register the provider (called from v8.cc). - Write events (called from libplatform/tracing-controller.cc) - Unregister the provider (called from v8.cc) At the base, we have an abstract provider class that encapsulates the functionality of an event provider. These are things like registering and unregistering the provider, and the actual event-logging. The provider class is split into provider-win and provider-mac (currently not instantiated) classes, with OS-dependent implementations of the above functions. In particular, the TraceLogging API is used only in provider-win. It is here that we forward declare and define the provider, as well as write ETW events. Finally, there is a v8-provider class that serves as a top-level API and is exposed to the rest of V8. It acts as a wrapper for the platform-specific providers. The .wprp file is needed so that Windows Performance Recorder knows how to capture our events. Some considerations: - Is TracingController::AddTraceEvent the best place from which to write my events? - Is src/libplatform/tracing the best place to put my instrumentation? - Right now, I fail the preupload because of this, which tells me my files are probably not in the best location: You added one or more #includes that violate checkdeps rules. src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h" Because of "-src/libplatform" from src's include_rules. Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf Bug: v8:11043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71918}
69 lines
2.8 KiB
XML
69 lines
2.8 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<WindowsPerformanceRecorder Version="1.0">
|
|
<!--
|
|
Note: The following utilities are usually installed to: "C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit"
|
|
See https://docs.microsoft.com/en-us/windows-hardware/test/wpt/ for an overview of the tools.
|
|
|
|
Start and stop the trace:
|
|
|
|
wpr -start wpr.wprp!V8js
|
|
...run scenario...
|
|
wpr -stop v8js.etl
|
|
|
|
You can also run "wpr -status collectors details" while recording to check on status.
|
|
|
|
Note: If you have issues with the command line, run WRPUI, and load this profile via the dialog.
|
|
|
|
Run the below to open the trace:
|
|
|
|
wpa v8js.etl
|
|
|
|
Set _NT_SYMBOL_PATH to a value such as "C:\src\v8\v8\out.gn\x64.debug;srv*c:\symbols*https://msdl.microsoft.com/download/symbols" first.
|
|
Append "-symcacheonly" on the WPA command to save it trying to reload prior failed symbols on subsequent runs.
|
|
|
|
For details on editing this file, see https://docs.microsoft.com/en-us/windows-hardware/test/wpt/authoring-recording-profiles
|
|
-->
|
|
<Profiles>
|
|
<SystemCollector Id="SystemCollector" Name="NT Kernel Logger">
|
|
<BufferSize Value="1024"/>
|
|
<Buffers Value="384"/>
|
|
</SystemCollector>
|
|
<EventCollector Id="EventCollector_V8js" Name="V8js Event Collector">
|
|
<BufferSize Value="1024"/>
|
|
<Buffers Value="256"/>
|
|
</EventCollector>
|
|
<SystemProvider Id="SystemProvider">
|
|
<Keywords>
|
|
<Keyword Value="ProcessThread"/>
|
|
<Keyword Value="Loader"/>
|
|
<Keyword Value="SampledProfile"/>
|
|
<Keyword Value="ReadyThread"/>
|
|
<Keyword Value="CSwitch"/>
|
|
<Keyword Value="DiskIOInit"/>
|
|
<Keyword Value="FileIOInit"/>
|
|
<Keyword Value="HardFaults"/>
|
|
</Keywords>
|
|
<Stacks>
|
|
<!-- See https://docs.microsoft.com/en-us/windows-hardware/test/wpt/stack-wpa for options -->
|
|
<Stack Value="SampledProfile"/>
|
|
<Stack Value="ReadyThread"/>
|
|
<Stack Value="CSwitch"/>
|
|
</Stacks>
|
|
</SystemProvider>
|
|
<EventProvider Id="Provider_V8js" Name="57277741-3638-4A4B-BDBA-0AC6E45DA56C" Level="5" Stack="true"></EventProvider>
|
|
<Profile Id="V8js.Verbose.File" Name="V8js" DetailLevel="Verbose" LoggingMode="File" Description="V8.js profile">
|
|
<Collectors>
|
|
<SystemCollectorId Value="SystemCollector">
|
|
<SystemProviderId Value="SystemProvider"></SystemProviderId>
|
|
</SystemCollectorId>
|
|
<EventCollectorId Value="EventCollector_V8js">
|
|
<EventProviders>
|
|
<EventProviderId Value="Provider_V8js"></EventProviderId>
|
|
</EventProviders>
|
|
</EventCollectorId>
|
|
</Collectors>
|
|
</Profile>
|
|
<Profile Id="V8js.Verbose.Memory" Base="V8js.Verbose.File" Name="V8js" DetailLevel="Verbose" LoggingMode="Memory" Description="V8.js profile"></Profile>
|
|
</Profiles>
|
|
</WindowsPerformanceRecorder>
|