Issue 11043 in v8: ETW Instrumentation

[sart… via monorail]

Status: Assigned
Owner: mache...@chromium.org
Components: Infrastructure
Type: Bug

New issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043

Design doc:
https://docs.google.com/document/d/2xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U

Various Windows performance tools, including Windows Performance Analyzer and Visual Studio Analyzer, rely on ETW (Event-Tracing for Windows) events for analysis.

One useful feature is that we can compare memory and other profiling information of user-defined events with kernel ones.

Another useful tool for analysis is the ability to walk through the call stack. Currently, in Windows Performance Analyzer, the call stack becomes obscured once the program enters interpreted or JIT-ted functions.

I anticipate 2-3 total changelists will be needed to fully instrument ETW:
- One that provides the core implementation + emits generic events
- One that adds onto the above CL and emits stack-walking events
- One that handles what kind of events we trace and other trace configurations

I'll do my best to answer any further questions anyone has about my particular
instrumentation or ETW in general :)

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[n… via monorail]

Updates:
Cc: ne...@chromium.org peterm...@chromium.org
Components: Tools
Owner: ----
Status: Untriaged

Comment #1 on issue 11043 by ne...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c1

The link doesn't work me: "Sorry, the file you have requested does not exist."

[sart… via monorail]

Comment #2 on issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c2

Sorry, here's there was a typo: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U

Could you please assign the case to me? I don't have EditBug access.

Also, here's the link to the first changelist: https://chromium-review.googlesource.com/c/v8/v8/+/2233407

[n… via monorail]

Updates:
Components: -Infrastructure
Labels: Priority-3 Type-FeatureRequest
Owner: cbr...@chromium.org
Status: Started

Comment #3 on issue 11043 by ne...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c3

Sorry, can't (Invalid arguments: Issue owner must be a project member.) Assigning to cbruni as I see he's reviewing the CL.

[sart… via monorail]

Comment #4 on issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c4

I just migrated V8Provider to inherit from metrics::Recorder. Here are some implementation notes / concerns / questions:
- The Isolate already had a SetMetricsRecorder member, so I used that to initialize the recorder. However, this implies that an Isolate can ever only have one recorder, and I can imagine scenarios where we would want more than one. For example, we may want to turn on both ETW and v8.log logging.
- I don't understand the difference between V8::Isolate and V8::internal::Isolate. On the one hand, I see them being used differently (see src/api/api.cc, Isolate::Initialize), where some things are initialized on the V8::Isolate and some things are initialized on the internal one. On the other hand, I also see them being cast back and forth (see src/logging/metrics.cc, Recorder::SetRecorder and the function that calls it, src/api/api.cc Isolate::SetMetricsRecorder).
- This kind of follows up from the previous point, but when we call AddMainThreadEvent from src/compiler/compile.cc, we're doing a lot of work before we actually do the function call: grabbing the context ID, creating the event, etc. I'm open to ideas for how to make this part of the code more streamlined.

[sart… via monorail]

Comment #5 on issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c5

As part of our efforts to prepare the Recorder interface for general use, we want to change the structure of the existing Wasm event structs. Because they are currently also instantiated in Chromium, we have a separate issue tracker for the changes specific to these structs: https://bugs.chromium.org/p/v8/issues/detail?id=11109.

[bugdroid via monorail]

Comment #6 on issue 11043 by bugdroid: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c6

The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/8b33c87239c35f665c39ad1c4030e06069e4e277

commit 8b33c87239c35f665c39ad1c4030e06069e4e277
Author: Sara Tang <sar...@microsoft.com>
Date: Tue Jan 05 20:11:03 2021

Step 1 (of 3-ish): Basic ETW Instrumentation in V8

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 <ul...@chromium.org>
Reviewed-by: Peter Marshall <peterm...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71918}

[add] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/src/libplatform/tracing/recorder-win.cc
[add] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/src/libplatform/tracing/recorder.h
[add] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/src/libplatform/tracing/recorder-default.cc
[modify] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/src/d8/d8.cc
[modify] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/BUILD.gn
[modify] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/src/d8/d8.h
[modify] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/src/libplatform/tracing/trace-writer.h
[add] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/tools/wpr.wprp
[modify] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/include/libplatform/v8-tracing.h
[modify] https://crrev.com/8b33c87239c35f665c39ad1c4030e06069e4e277/src/libplatform/tracing/trace-writer.cc

[sart… via monorail]

Updates:
Cc: -ne...@chromium.org -peterm...@chromium.org

Comment #7 on issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c7

Link to the second step (aka stack-walking): https://chromium-review.googlesource.com/c/v8/v8/+/2616221

[bugdroid via monorail]

Comment #8 on issue 11043 by bugdroid: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c8

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/88926769783fecb3bd3b08a7a0cb702b037d9f85

commit 88926769783fecb3bd3b08a7a0cb702b037d9f85
Author: Sara Tang <sar...@microsoft.com>
Date: Tue Mar 02 21:53:52 2021

Step 2 (of 2) for ETW integration into V8

Design doc:
https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U

This is the second (and hopefully final!) change list needed to
integrate ETW into V8. In particular, we added stack-walking
functionality for JIT-ted functions!

Some notes on instrumentation:
- The gist of getting stack-walking in ETW is we need to emit events
with specific event IDs. These events get stitched into a pseudo-PDB
that is recognizable by ETW.
- Unfortunately, we cannot rely on the TraceLogging API from the first
CL, as it does not support specifying event IDs. Instead, Bill
Ticehurst wrote an API that peels back the TraceLogging API just
enough so that we can specify event IDs. This API is the entirety of
etw-metdata.h
- We attach a CodeEventHandler that logs a stack-walking event whenever
code movement is triggered.

Bug: v8:11043
Change-Id: I1bf57c985b7375f045089027855b1c03878abb78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616221
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Reviewed-by: Ulan Degenbaev <ul...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73145}

[modify] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/libplatform/tracing/recorder-win.cc
[modify] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/libplatform/tracing/recorder.h
[add] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/diagnostics/system-jit-win.h
[add] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/diagnostics/system-jit-metadata-win.h
[add] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/diagnostics/system-jit-win.cc
[modify] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/BUILD.gn
[modify] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/DEPS
[modify] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/init/v8.cc
[modify] https://crrev.com/88926769783fecb3bd3b08a7a0cb702b037d9f85/src/api/api.cc

[bruce… via monorail]

Comment #9 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c9

What is the plan for turning this on (setting v8_enable_system_instrumentation to true) in shipping builds of Chrome?

What would be needed to record this data in UIforETW? Looking at wpr.wprp it looks like I would have to record the 57277741-3638-4A4B-BDBA-0AC6E45DA56C provider with level 5. I'm not sure how to interpret the Stack = true flag.

UIforETW just shells out to xperf.exe to start and stop trace recording so I guess I'm basically asking how to record the V8js data using xperf.

[sart… via monorail]

Comment #10 on issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c10

I just ran some perf labs last night with the flag on/off and I'm trying to assess whether or not there's significant overhead if we turn on the flag but don't run any ETW recorders. If not, I think I'll have a convincing argument to have it on by default.

I'm not too familiar with running UIforETW/xperf so I'll get back to you on that.

[bruce… via monorail]

Comment #11 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c11

Thanks!

UIforETW is a UI for recording ETW traces with some convenience features and a few Chrome helpers included. The public instructions are here, and the releases link goes to the github repo:

https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/

[sart… via monorail]

Updates:
Owner: sart...@microsoft.com

Comment #12 on issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c12

I was able to capture a .etl trace using xperf by running this command as admin:

```
xperf -start perf!GeneralProfiles.InSequentialFile -on 57277741-3638-4A4B-BDBA-0AC6E45DA56C && out\x64.debug\d8.exe --enable-system-instrumentation C:\sandbox\etw-demo.js && xperf -stop perf!GeneralProfiles.InSequentialFile trace.etl
```

It doesn't capture the exact same data as if you were to run wpr.wprp+WPRUI, but I believe that would require writing a xperf logger (which I can try and get to you). In particular, it doesn't capture the kernel events specified by stacks in the wpr.wprpr:

```
<Stacks>
<Stack Value="SampledProfile"/>
<Stack Value="ReadyThread"/>
<Stack Value="CSwitch"/>
</Stacks>
```

[Git Watcher via monorail]

Comment #13 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c13

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/07f972713b8f9abc28cf97dc3824bd09e4fc44c8

commit 07f972713b8f9abc28cf97dc3824bd09e4fc44c8
Author: Sara Tang <sar...@microsoft.com>
Date: Fri Mar 12 23:03:04 2021

[diagnostics] Only conditionally enable ETWJITInterface

While testing the perf for v8-etw, I noticed that the runtime flag
didn't completely guard from event emission. This change fixes that.

Bug: v8:11043
Change-Id: Iee919e6030214e18173c93e4426d6437aed08235
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2757894
Reviewed-by: Ulan Degenbaev <ul...@chromium.org>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73424}

[modify] https://crrev.com/07f972713b8f9abc28cf97dc3824bd09e4fc44c8/src/api/api.cc
[modify] https://crrev.com/07f972713b8f9abc28cf97dc3824bd09e4fc44c8/src/d8/d8.cc
[modify] https://crrev.com/07f972713b8f9abc28cf97dc3824bd09e4fc44c8/src/flags/flag-definitions.h
[modify] https://crrev.com/07f972713b8f9abc28cf97dc3824bd09e4fc44c8/src/init/v8.cc

[Git Watcher via monorail]

Comment #14 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c14

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/0b56c19165d47824e335b6e69d6d3b19921ec9d7

commit 0b56c19165d47824e335b6e69d6d3b19921ec9d7
Author: Sara Tang <sar...@microsoft.com>
Date: Tue Mar 16 09:48:46 2021

[diagnostics] ETW should emit interpreted functions on the callstack

This is a small change to the ETW instrumentation to enable
--interpreted-frames-native-stack so that we can see intepreted
functions on the JS call stack (in addition to jit-ted ones).

Bug: v8:11043
Change-Id: I17870bda6bc5291d6fe429770a015dd803fe446b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2757888

Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>

Cr-Commit-Position: refs/heads/master@{#73451}

[modify] https://crrev.com/0b56c19165d47824e335b6e69d6d3b19921ec9d7/src/d8/d8.cc
[modify] https://crrev.com/0b56c19165d47824e335b6e69d6d3b19921ec9d7/src/flags/flag-definitions.h

[zhen… via monorail]

Comment #15 on issue 11043 by zhen...@gmail.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c15

I noticed the provider GUID being used here is the Microsoft-JScript provider's - which makes sense, since tools already use it for IE/Edge Chakra js symbols. However, this means the xperf command and the provided WPR profile should *NOT* be used - they enable (with stack traces) all Microsoft-JScript events, including GC Heap allocations for both Chakra and Trident. Some applications I've worked with can have bursts exceeding a million allocations a second, and logging stack traces for them has a severe performance impact (and probably overwhelms your trace buffers).

A more appropriate xperf command would be along the lines of:

xperf -start JSStacks -on Microsoft-JScript:0x3


And for a WPR profile:

<EventProvider Id="Provider_V8js" Name="57277741-3638-4A4B-BDBA-0AC6E45DA56C">
<Keywords>
<Keyword Value="0x1"/>
</Keywords>
<CaptureStateOnSave>
<Keyword Value="0x4"/>
</CaptureStateOnSave>
</EventProvider>

[bruce… via monorail]

Comment #16 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c16

I gave this a try today. I built a release build of Chromium with v8_enable_system_instrumentation=true, synced to today's version of code. I then recorded an ETW trace with Microsoft-JScript:0x3 added to the list of user-mode providers. I ran some JavaScript and got call stacks that look like this:

| | | | | | chrome.dll!blink::V8ScriptRunner::CallFunction
| | | | | | |- chrome.dll!v8::Function::Call
| | | | | | | chrome.dll!v8::internal::Execution::Call
| | | | | | | chrome.dll!v8::internal::`anonymous namespace'::Invoke
| | | | | | | ?!?
| | | | | | | ?!?
...
| | | | | | | | | | | |- ?!?
| | | | | | | | | | | | |- chrome.dll!v8::internal::Builtin_HandleApiCall
| | | | | | | | | | | | | chrome.dll!v8::internal::Builtin_Impl_HandleApiCall
| | | | | | | | | | | | | chrome.dll!v8::internal::`anonymous namespace'::HandleApiCallHelper<0>
| | | | | | | | | | | | | chrome.dll!v8::internal::FunctionCallbackArguments::Call
| | | | | | | | | | | | | chrome.dll!blink::`anonymous namespace'::v8_data_transfer_item::GetAsFileOperationCallback
| | | | | | | | | | | | | chrome.dll!blink::DataObjectItem::GetAsFile

The call stacks look good - there were 22 ?!? entries and it seems to make sense - but no function names.

I then tried again being careful to start tracing before launching Chromium (since there is no rundown support) and got the same results.

I then tried with Chrome stable - without these changes. Instead of ?!? I got lots of chrome.dll!Builtins_InterpreterEntryTrampoline, shown here:

| | | | | | | | | chrome.dll!blink::V8ScriptRunner::CallFunction
| | | | | | | | | |- chrome.dll!v8::Function::Call
| | | | | | | | | | chrome.dll!v8::internal::Execution::Call
| | | | | | | | | | chrome.dll!v8::internal::`anonymous namespace'::Invoke
| | | | | | | | | | chrome.dll!Builtins_JSEntry
| | | | | | | | | | chrome.dll!Builtins_JSEntryTrampoline
| | | | | | | | | | |- chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | |- chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | | |- chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | | | |- chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | | | | |- chrome.dll!Builtins_ArrayMap
| | | | | | | | | | | | | | | chrome.dll!Builtins_InterpreterEntryTrampoline
| | | | | | | | | | | | | | | |- chrome.dll!Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit
| | | | | | | | | | | | | | | | chrome.dll!v8::internal::Builtin_HandleApiCall
| | | | | | | | | | | | | | | | chrome.dll!v8::internal::Builtin_Impl_HandleApiCall
| | | | | | | | | | | | | | | | chrome.dll!v8::internal::`anonymous namespace'::HandleApiCallHelper<0>
| | | | | | | | | | | | | | | | chrome.dll!v8::internal::FunctionCallbackArguments::Call
| | | | | | | | | | | | | | | | chrome.dll!blink::`anonymous namespace'::GetAsFileOperationCallback
| | | | | | | | | | | | | | | | chrome.dll!blink::DataObjectItem::GetAsFile

I'm not sure what to make of this. I was using https://evercoder.github.io/clipboard-inspector/ as a test site, pasting in a medium-sized bitmap from the clipboard.

My UIforETW changes can be found at https://github.com/google/UIforETW/tree/jscript

[sart… via monorail]

Comment #17 on issue 11043 by sart...@microsoft.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c17

Just to check, did you launch msedge with --js-flags="--enable-system-instrumentation"? There is both a build and runtime flag, I have a CL open to turn the build flag on by default, the runtime flag is harder to do.

[bruce… via monorail]

Comment #18 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c18

I'm actually testing with chrome.exe, but your point stands, and that does the trick! The function names are a bit ugly but they look plausible.

It's odd that the .js path ends up twice in the function name (with ~lazyCompile:~uo or similar in-between) but since it's just a randomly chosen website I really don't know what to expect.

Presumably the results would be more readable if I wasn't profiling minimize JavaScript, but even as-is it seems to have grand potential.

[Git Watcher via monorail]

Comment #19 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c19

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/f0061332ef9c23e7156221c4d5c5469431f95ff3

commit f0061332ef9c23e7156221c4d5c5469431f95ff3
Author: Sara Tang <sar...@microsoft.com>
Date: Tue Mar 30 23:06:25 2021

[diagnostics] Enable ETW stack-walking events build flag

Feedback from Microsoft partners indicates that it would be beneficial
to enable ETW stack-walking events by default.

This is difficult, because the --interpreted-frames-native-stack flag
comes with a significant perf degradation. Ideally, we would turn
this flag on dynamically, only when a ETW recorder is actively
triggering the provider. Unfortunately, the flag in its current state
cannot be enabled dynamically.

In light of this, we have decided to only flip the build flag.

Bug: v8:11043
Change-Id: Id883b9bcd635b41139450ab2d5c92511422525a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773792

Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>

Cr-Commit-Position: refs/heads/master@{#73784}

[modify] https://crrev.com/f0061332ef9c23e7156221c4d5c5469431f95ff3/BUILD.gn
[modify] https://crrev.com/f0061332ef9c23e7156221c4d5c5469431f95ff3/src/d8/d8.cc
[modify] https://crrev.com/f0061332ef9c23e7156221c4d5c5469431f95ff3/src/diagnostics/system-jit-win.cc
[modify] https://crrev.com/f0061332ef9c23e7156221c4d5c5469431f95ff3/src/libplatform/tracing/recorder-win.cc

[Git Watcher via monorail]

Comment #20 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c20

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/f0399fa1d9b446f192e7afe84f377b38965854d0

commit f0399fa1d9b446f192e7afe84f377b38965854d0
Author: Camillo Bruni <cbr...@chromium.org>
Date: Tue Apr 06 15:00:40 2021

[diagnostics] Disable system instrumentation by default

Disabling temporarily since it breaks chrome cross-builds on linux.

Bug: v8:11043, chromium:1196278
Change-Id: I2d2a0c8b88b357da52217d1672aaa1377759df07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2805816
Commit-Queue: Camillo Bruni <cbr...@chromium.org>
Reviewed-by: Patrick Thier <pth...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73809}

[modify] https://crrev.com/f0399fa1d9b446f192e7afe84f377b38965854d0/BUILD.gn

[Git Watcher via monorail]

Comment #21 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c21

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/05a89f9382b21625c811d77b62ade137da5425d3

commit 05a89f9382b21625c811d77b62ade137da5425d3
Author: Sara Tang <sar...@microsoft.com>
Date: Wed Apr 07 00:46:32 2021

Guard system-instrumentation with V8_OS_WIN instead of V8_TARGET_OS_WIN. Re-enable ENABLE_SYSTEM_INSTRUMENTATION

Bug: v8:11043, chromium:1196278

Change-Id: I3c3ab07de909ad5b58dd9a99740ff5f59ab8165f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2809530
Reviewed-by: Nico Weber <tha...@chromium.org>
Reviewed-by: Ulan Degenbaev <ul...@chromium.org>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Reviewed-by: Patrick Thier <pth...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73821}

[modify] https://crrev.com/05a89f9382b21625c811d77b62ade137da5425d3/BUILD.gn
[modify] https://crrev.com/05a89f9382b21625c811d77b62ade137da5425d3/src/api/api.cc
[modify] https://crrev.com/05a89f9382b21625c811d77b62ade137da5425d3/src/init/v8.cc

[Git Watcher via monorail]

Comment #22 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c22

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/e5b4a5ede31adbab00287822d6975531d9be4515

commit e5b4a5ede31adbab00287822d6975531d9be4515
Author: Sara Tang <sar...@microsoft.com>
Date: Wed Apr 07 17:14:43 2021

[diagnostics] system instrumentation for MacOS

This CL implements the equivalent of ETW in macos (called Signposts)

Bug: v8:11043
Change-Id: Ifa72cfd17fca81b18e3e8b1003fd6ab72de3c986
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2807157
Commit-Queue: Sara Tang <sar...@microsoft.com>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73856}

[modify] https://crrev.com/e5b4a5ede31adbab00287822d6975531d9be4515/BUILD.gn
[modify] https://crrev.com/e5b4a5ede31adbab00287822d6975531d9be4515/src/d8/d8.cc
[add] https://crrev.com/e5b4a5ede31adbab00287822d6975531d9be4515/src/libplatform/tracing/recorder-mac.cc
[modify] https://crrev.com/e5b4a5ede31adbab00287822d6975531d9be4515/src/libplatform/tracing/recorder.h

[Git Watcher via monorail]

Comment #23 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c23

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/41fb9f9724bc2c8f18310f7a0b471dd64fd941bc

commit 41fb9f9724bc2c8f18310f7a0b471dd64fd941bc
Author: Sara Tang <sar...@microsoft.com>
Date: Fri Apr 09 20:41:42 2021

[diagnostics] Fix macos system instrumentation for ios-sim

Original CL: https://chromium-review.googlesource.com/c/v8/v8/+/2807157

Bug: v8:11043
Change-Id: I49d29323bf3ae6ede7e48e63645f4ee0a750c83e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2818573
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73931}

[modify] https://crrev.com/41fb9f9724bc2c8f18310f7a0b471dd64fd941bc/BUILD.gn
[modify] https://crrev.com/41fb9f9724bc2c8f18310f7a0b471dd64fd941bc/src/d8/d8.cc

[Git Watcher via monorail]

Comment #24 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c24

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/a154ce984ac822cbea2700c5e855e7c4efcb5dea

commit a154ce984ac822cbea2700c5e855e7c4efcb5dea
Author: Sara Tang <sar...@microsoft.com>
Date: Fri Apr 16 19:38:10 2021

[diagnostics] Fix node-v8 build

Turning on V8_ENABLE_SYSTEM_INSTRUMENTATION by default has broken
node-v8 builds on Windows, tracked here:
https://github.com/nodejs/node-v8/issues/192. It looks like it is due
to the fact that Node uses pre-compiled headers, which undefines
some macros needed for the event trace APIs to work. (see
src/base/win32-headers.h)

Bug: v8:11043
Change-Id: I3a6caeaaabab59d42e14b79defb2e37efd9ad04d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2830550

Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>

Cr-Commit-Position: refs/heads/master@{#74080}

[modify] https://crrev.com/a154ce984ac822cbea2700c5e855e7c4efcb5dea/src/diagnostics/system-jit-metadata-win.h

[zhen… via monorail]

Comment #25 on issue 11043 by zhen...@gmail.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c25

I finally got a chance to test this out today.

The first thing that stands out to me is that the function names are not very good; they include a lot of extra noise and they omit important information. For example...
Chrome:
https://dev-server/Bundle.js!LazyCompile:~endUpdate https://dev-server/Bundle.js:3-0:0 0x0
IE11:
https://dev-server/Bundle.js!a.Observer._observeMethods.endUpdate-3:38995 0x0


While comparing more closely, I noticed some functional problems.

Without MethodUnload events, WPA (and presumably other tools) can be confused by overlapping methods at different base addresses.
For example, I had one method emitted with:
MethodStartAddress="0x00002A470054CC40" MethodSize="1,260" MethodName="OldFunction"
and then 12 seconds later this was emitted:
MethodStartAddress="0x00002A470054CC60" MethodSize="1,260" MethodName="NewFunction"

A subsequent stack trace has a stack level at 0x2A470054CD41, which shows the correct "NewFunction" name in WPA 16299, but WPA 19041 shows "OldFunction" incorrectly.

Deeper down the stack, there are a lot more mixups where neither version gets the right answer.


Also, all of the events are being emitted with tracelogging Start opcodes rather than the Info opcode they should. WPA 16299 emits a bunch of complaints to the log about it, and I suspect it's preventing PerfView from interpreting stack traces using them.

[zhen… via monorail]

Comment #26 on issue 11043 by zhen...@gmail.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c26

Never mind on the stack resolution functional problem - I usually record my traces with stack caching turned on, and apparently neither WPA or PerfView handle resolving a single stack key entry to multiple distinct functions.

PerfView is getting confused by the tracelogging metadata (it assumes the event ID isn't populated and overwrites it with a generated one).


I've noticed one other issue with the function names. The ~,+, and * that appear after the "LocalFunction:" are based on the JIT level, so a given function can show up with two or three different names, splitting up the stacks and making code analysis harder

[Git Watcher via monorail]

Comment #27 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c27

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/205338ceb34778e901db110b58979a5d36753da4

commit 205338ceb34778e901db110b58979a5d36753da4
Author: Sara Tang <sar...@microsoft.com>
Date: Mon Jun 21 22:40:49 2021

[diagnostics] Added line numbers to ETW JIT events

Feedback suggests that it would be easier to trace minified JS code if
line numbers were included in the ETW JIT events, so I added them.

Bug: v8:11043
Change-Id: I1660c695db2e4659184b2b679839dafe256fb3ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2971625

Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Sara Tang <sar...@microsoft.com>

Cr-Commit-Position: refs/heads/master@{#75290}

[modify] https://crrev.com/205338ceb34778e901db110b58979a5d36753da4/src/d8/d8.cc
[modify] https://crrev.com/205338ceb34778e901db110b58979a5d36753da4/src/diagnostics/system-jit-win.cc

[bruce… via monorail]

Comment #28 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c28

What is the status of this? I built Chromium with v8_enable_system_instrumentation = true and passed --enable-system-instrumentation as a command-line argument (that should be more discoverable) but I'm still getting no names for V8 functions. This is on a release non-component x64 Windows build.

I noticed that --enable-system-instrumentation doesn't seem to get passed along to the renderer processes, which I assume is supposed to happen. Command-line arguments need to be explicitly passed along.

That said, I thought this used to work, so, ???

[cbr… via monorail]

Comment #29 on issue 11043 by cbr...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c29

Hi, could you paste the exact command line arguments you used?

[bruce… via monorail]

Comment #30 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c30

out\release\chrome.exe --enable-system-instrumentation

[cbr… via monorail]

Comment #31 on issue 11043 by cbr...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c31

--enable-system-instrumentation is a v8-only flag, can you try passing it via --js-flags="--enable-system-instrumentation" ?

[henr… via monorail]

Updates:
Labels: OS-Windows

Comment #32 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c32

Tried building latest Chrome on Windows using v8_enable_system_instrumentation as build flag and also launched Chrome with

--js-flags="--enable-system-instrumentation"

Created an ETL file using UIfoETW with "Trace JavaScript" enabled.

Still can't resolve the complete stack in v8 and parts of the call stack becomes obscured. See attached screenshot.

Any ideas on how to figure out where things break?

Attachments:
v8.png 50.9 KB

[bruce… via monorail]

Comment #33 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c33

Comment#32 matches my results. With that UIforETW setting checked (adds Microsoft-JScript:0x3 to the list of providers recorded) and with that command-line argument, running 64-bit Chrome on Windows 10 21H2, I get call stacks but no names for entries within JavaScript.

I tried examining src\v8\tools\wpr.wprp to see if I was using the wrong provider name to record the events but I couldn't make any of the obvious options work.

[zhen… via monorail]

Comment #34 on issue 11043 by zhen...@gmail.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c34

I gave it a try and I'm also not getting any javascript symbols (using Chrome 99). I don't think it's a tracing config issue, since I was successfully getting symbols from an Electron app earlier this week with the same flag argument & tracing commands.

[jdap… via monorail]

Comment #35 on issue 11043 by jdap...@igalia.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c35

Using bisect-builds.py I see the change comes in this range:
https://chromium.googlesource.com/chromium/src/+log/310583b19d6595520796c6ee7ec67a2496a82797..6e697436823e0840549609f5b19c06fda1254205

Though, I don't see a clear candidate to have introduced the regression (only maybe --js-flags fix... maybe it changed processing in a way that now the required flags are not passed when they should?).

[bruce… via monorail]

Comment #36 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c36

It looks like there are two bugs:

1) The enable_system_instrumentation flag defined in flag-definitions.h is never getting set.
2) If that flag is set (by modifying its definition to default to true) then Chromium doesn't work correctly. Proxy resolution fails, presumably because proxy resolution requires running a small amount of JavaScript.

That is, I modified flag-definitions.h to make this change and then Chromium no longer worked:

-DEFINE_BOOL(enable_system_instrumentation, false,
+DEFINE_BOOL(enable_system_instrumentation, true,

Chromium can load cached pages but cannot navigate

[bruce… via monorail]

Comment #37 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c37

V8 JS hangs when I force enable_system_instrumentation to true because EnforceFlagImplications gets in to an infinite loop on a Proxy Resolver thread, which I guess means I've set an illegal set of flags. It's tough to debug what's going on because the code in EnforceFlagImplications is all #included in, and is running macro generated code.

There's probably some easy fix to this, but I can't figure out what it is. Getting into an infinite loop seems surprising, given how difficult it appears to be for non-experts to understand why.

I instrumented TriggerImplication and it repeatedly prints these two messages:

enable_system_instrumentation changed from 1 to 0 (weak implication is 0).
jitless changed from 0 to 1 (weak implication is 0).

I don't understand why they keep changing and what keeps changing them back. But, with the indication that jitless was involved I commented out the line that enables jitless for the proxy resolver.

With that done Chromium started working again. I grabbed a trace and saw a lot of samples that looked like ETW instrumentation overhead, such as chrome.dll!v8::internal::Script::GetLineNumber but when JS functions were actually called it was the same old ?!?

| | | | | | | | | | | | |- chrome.dll!v8::internal::Execution::Call
| | | | | | | | | | | | | |- chrome.dll!v8::internal::Execution::Call
| | | | | | | | | | | | | | |- ?!?
| | | | | | | | | | | | | | | ?!?
| | | | | | | | | | | | | | | |- ?!?

My diffs were:

diff --git a/services/proxy_resolver/proxy_resolver_v8.cc b/services/proxy_resolver/proxy_resolver_v8.cc
index 2cf0db05d56b6..41f881a5d361d 100644
--- a/services/proxy_resolver/proxy_resolver_v8.cc
+++ b/services/proxy_resolver/proxy_resolver_v8.cc
@@ -397,8 +397,8 @@ class SharedIsolateFactory {

// Running v8 in jitless mode allows dynamic code to be disabled in the
// process.
- static const char kJitless[] = "--jitless";
- v8::V8::SetFlagsFromString(kJitless, strlen(kJitless));
+ //static const char kJitless[] = "--jitless";
+ //v8::V8::SetFlagsFromString(kJitless, strlen(kJitless));

// WebAssembly isn't encountered during resolution, so reduce the
// potential attack surface.



diff --git a/src/flags/flag-definitions.h b/src/flags/flag-definitions.h
index 4e71838e2c..87bfd55a2d 100644
--- a/src/flags/flag-definitions.h
+++ b/src/flags/flag-definitions.h
@@ -2118,12 +2118,12 @@ DEFINE_BOOL_READONLY(
"Show interpreted frames on the native stack (useful for external "
"profilers).")
#else
-DEFINE_BOOL(interpreted_frames_native_stack, false,
+DEFINE_BOOL(interpreted_frames_native_stack, true,
"Show interpreted frames on the native stack (useful for external "
"profilers).")
#endif

-DEFINE_BOOL(enable_system_instrumentation, false,
+DEFINE_BOOL(enable_system_instrumentation, true,
"Enable platform-specific profiling.")

#ifndef V8_TARGET_ARCH_ARM

[henr… via monorail]

Updates:
Labels: Priority-2

Comment #38 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c38

Increasing priority since our team would really appreciate if this issue was fixed as soon as possible. We are having performance issues related to JS but lack the ability to resolve what part of the code is causing it.

[jdap… via monorail]

Comment #39 on issue 11043 by jdap...@igalia.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c39

I think I found the problem, and proposed fix https://chromium-review.googlesource.com/c/chromium/src/+/3529090

The original fix for simplifying --js-flags processing and moving it to V8Initializer::Initialize was making flags processed after v8 initialization. But system instrumentation initialization code happens in v8 platform initialization before the code that sets the JS flags.

The fix I propose just moves JS flags processing so it happens before v8 initialization happens.

[bruce… via monorail]

Comment #40 on issue 11043 by bruce...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c40

The fix seems to work! I reverted my experimental changes, patched in 3529090 to my chromium repo, then ran this command:

out\release\chrome.exe --js-flags="--enable-system-instrumentation"

I then enabled Trace JavaScript in UIforETW and I got this call stack:

| chrome.dll!v8::internal::Execution::TryCallScript
| chrome.dll!v8::internal::Execution::Call
| ?!?
| ?!?
| ?!?
| |- ?!?
| |- https://hb.vntsm.com/v3/live/ad-manager.min.js!LazyCompile:~ https://hb.vntsm.com/v3/live/ad-manager.min.js:2-2:0 0x0
| |- https://player.aniview.com/script/6.1/AVmanager.js?v=1.0&type=s&pid=5f2063121d82c82557194737!LazyCompile:~ https://player.aniview.com/script/6.1/AVmanager.js?v=1.0&type=s&pid=5f2063121d82c82557194737:4-4:0 0x0
| |- https://player.aniview.com/script/6.1/AVmanager.js?v=1.0&type=s&pid=5f2063121d82c82557194737!LazyCompile:~s https://player.aniview.com/script/6.1/AVmanager.js?v=1.0&type=s&pid=5f2063121d82c82557194737:4-4:0 0x0
| |- chrome.dll!v8::internal::Runtime_RunMicrotaskCallback
| |- https://player.aniview.com/script/6.1/AVmanager.js?v=1.0&type=s&pid=5f2063121d82c82557194737!LazyCompile:~ht.then https://player.aniview.com/script/6.1/AVmanager.js?v=1.0&type=s&pid=5f2063121d82c82557194737:4-4:0 0x0

I don't know why some of the functions didn't get names, but it's great to see that most of them did get names. Thanks.

[henr… via monorail]

Comment #41 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c41

Thanks for contributing jda...@igalia.com!

I also tried the fix and can see new contributions to the call stack in many places but also that most parts related to v8::internal is still missing for me.

In all the tests below I enabled the JavaScript flag in UIforETW and started and stopped tracing while the special build of Chromium was running.

I started out using https://evercoder.github.io/clipboard-inspector/ as a test site, pasting in small text file from the clipboard while running Chrome with --js-flags="--enable-system-instrumentation" and the suggested patch.

The result seen in 'evercoder.png' shows new parts that look promising:

chrome.dll!blink::V8ScriptRunner::CallFunction

chrome.dll!v8::Function::Call
chrome.dll!v8::internal::Execution::Call
chrome.dll!v8::internal::`anonymous namespace'::Invoke
?!?
?!?

|- $JScriptDynamic$!LazyCompile:~id https://evercoder.github.io/clipboard-inspector/index.js:2036-2036:0 0x0
| ?!?
| $JScriptDynamic$!LazyCompile:~hd https://evercoder.github.io/clipboard-inspector/index.js:2039-2039:0 0x0
| $JScriptDynamic$!LazyCompile:~yc https://evercoder.github.io/clipboard-inspector/index.js:2064-2064:0 0x0
| |- $JScriptDynamic$!LazyCompile:~jd https://evercoder.github.io/clipboard-inspector/index.js:2576-2576:0 0x0
| | $JScriptDynamic$!LazyCompile:~Nb https://evercoder.github.io/clipboard-inspector/index.js:1406-1406:0 0x0
| | $JScriptDynamic$!LazyCompile:~Jb https://evercoder.github.io/clipboard-inspector/index.js:6952-6952:0 0x0
| | |- ?!?
| | | ?!?
| | | chrome.dll!v8::internal::Runtime_CompileLazy
| | | chrome.dll!v8::internal::__RT_impl_Runtime_CompileLazy
| | | chrome.dll!v8::internal::Compiler::Compile
| | | chrome.dll!v8::internal::Compiler::Compile

See also 'evercoder.png' for more details.

These new parts are missing if I run my patched Chrome without --js-flags="--enable-system-instrumentation". There are however still many missing parts.

So far so good.

I then tried a more complex application like Google Meet, which does way more in JavaScript, I can't say for sure if new parts are added or not. What I can say is that there are still many missing parts.

'meet_v8_js_flag.png' shows one segment from WPA with missing parts in the call stack.

'pprof_meet_v8_internal.png' shows all stacks which contains v8::internal and that there are still many "holes" marked with unknown since the parser fails to find proper symbols.

The complete pprof profile for the Meet test can be found at (Google internal, sorry): https://pprof.corp.google.com/?id=ca641a8f315acc319d1c22a70448684d

Possible reasons for not getting perfect results:

- Using the tools the wrong way.
- Missing some essential step that will add more details to the stack in JS.
- Are changes in the JS client required?
- Invalid build flags (see [1] for GN alias).
- Lack of understanding of what to expect.

Not sure where to go from here but I would really like to be able to fill in the gaps presented above.

[1] alias crgenr_ext='gn gen out/Release --args="is_debug=false is_component_build=false v8_enable_system_instrumentation=true blink_symbol_level=1 enable_hangout_services_extension=true use_goma=true ffmpeg_branding=\"Chrome\""'

Attachments:
evercoder.png 99 KB
meet_v8_js_flag.png 47.4 KB
pprof_meet_v8_internal.png 520 KB

[Git Watcher via monorail]

Comment #42 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c42

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src/+/40818448da7a4c637ec546d649ddf62e5cb01123

commit 40818448da7a4c637ec546d649ddf62e5cb01123
Author: Jose Dapena Paz <jda...@igalia.com>
Date: Mon Mar 21 11:36:35 2022

gin: set JS flags before v8 initialization

Fixed a regression that broke JS ETW instrumentation in Chromium after
commit dcd255e349c35228be35f2f43232a2b1c5605e80, that simplified
processing of --js-flags parameter on launch.

The original patch moved all processing to V8Initializer::Initialize
end. But that meant processing flags after all V8 initialization.
This would skip the code to set up system instrumentation support.

Bug: v8:11043
Change-Id: Ic88995d26f2c4cf8847698357cc336726e540d55
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3529090
Reviewed-by: Bruce Dawson <bruce...@chromium.org>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: José Dapena Paz <jda...@igalia.com>
Cr-Commit-Position: refs/heads/main@{#983264}

[modify] https://crrev.com/40818448da7a4c637ec546d649ddf62e5cb01123/gin/v8_initializer.cc

[Git Watcher via monorail]

Comment #43 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c43

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/ede0a4abeeb7c8c3262e97c02c62c1d93f732f09

commit ede0a4abeeb7c8c3262e97c02c62c1d93f732f09
Author: henrika <hen...@chromium.org>
Date: Mon Mar 28 10:33:46 2022

Ensures that Builtin events are sent to JIT-code event handlers

Generates callbacks for already existent code by using the
kJitCodeEventEnumExisting option instead of kJitCodeEventDefault.

When working on V8 system instrumentation on Windows, it was found in
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c41 that several
parts of the JS stack was missing.

One missing part is all calls to Builtin methods
(example: Builtin:JSEntryTrampoline) and this change ensures that
events with name "Builtin" are also included in the generated JIT code
events.

Bug: v8:11043
Change-Id: Iaa99e18d799266a7224f848130c4eaf36e8c77fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3550590
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Henrik Andreasson <hen...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79640}

[modify] https://crrev.com/ede0a4abeeb7c8c3262e97c02c62c1d93f732f09/src/api/api.cc

[henr… via monorail]

Updates:
Cc: hen...@chromium.org

Comment #44 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c44

(No comment was entered for this change.)

[Git Watcher via monorail]

Comment #45 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c45

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/ec778f9a029043531697f4c69a15a1ee46f6feb0

commit ec778f9a029043531697f4c69a15a1ee46f6feb0
Author: henrika <hen...@chromium.org>
Date: Thu Apr 07 13:18:32 2022

[logging][profiling] Log BytecodeHandler code in JIT loggers

Local tests on Windows using the --enable-system-instrumentation flag
in combination with ETW have shown that parts of the JS stack miss
symbols and most of these missing parts comes from
code-creation,Bytecodehandler events.

The CL fixes this issue.

Bug: v8:11043
Change-Id: I77b150742e689a4002dbc5937d6daa08a0795ab9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3574545

Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Henrik Andreasson <hen...@chromium.org>

Cr-Commit-Position: refs/heads/main@{#79858}

[modify] https://crrev.com/ec778f9a029043531697f4c69a15a1ee46f6feb0/src/logging/log.h
[modify] https://crrev.com/ec778f9a029043531697f4c69a15a1ee46f6feb0/src/logging/log.cc

[Git Watcher via monorail]

Comment #46 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c46

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/f5012c1a5ff6b5f5f7e13dc79d28d9c082a69726

commit f5012c1a5ff6b5f5f7e13dc79d28d9c082a69726
Author: henrika <hen...@chromium.org>
Date: Wed Apr 13 07:33:45 2022

Refactors JitLogger initialization for ETW and GDB.

Goal is to ensure that the JitLogger for ETW (on Windows) is more inline
with other CodeEventLoggers such as PerfJitLogger.

The new design ensures that initial Builtin and BytecodHandler events
are emitted to and received by the ETWJITInterface::EventHandler.

Bug: v8:11043
Change-Id: I5741053c387b9ac63a42de61c99f4ea4ae4bdb96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581769
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Reviewed-by: Jakob Linke <jgr...@chromium.org>
Commit-Queue: Henrik Andreasson <hen...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79949}

[modify] https://crrev.com/f5012c1a5ff6b5f5f7e13dc79d28d9c082a69726/src/execution/isolate.cc
[modify] https://crrev.com/f5012c1a5ff6b5f5f7e13dc79d28d9c082a69726/src/logging/log.h
[modify] https://crrev.com/f5012c1a5ff6b5f5f7e13dc79d28d9c082a69726/src/init/v8.cc
[modify] https://crrev.com/f5012c1a5ff6b5f5f7e13dc79d28d9c082a69726/src/api/api.cc
[modify] https://crrev.com/f5012c1a5ff6b5f5f7e13dc79d28d9c082a69726/src/logging/log.cc

[henr… via monorail]

Updates:
Cc: es...@chromium.org

Comment #47 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c47

(No comment was entered for this change.)

[henr… via monorail]

Updates:
Cc: hand...@chromium.org

Comment #48 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c48

[Git Watcher via monorail]

Comment #49 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c49

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/fee2336535714a2ee4018f02bcf7e258b1bd8ed8

commit fee2336535714a2ee4018f02bcf7e258b1bd8ed8
Author: henrika <hen...@chromium.org>
Date: Mon May 09 12:40:45 2022

[api] Adds script column number to code-creation events in CodeEventLogger

Bug: v8:11043
Change-Id: I8cbdd8a5f68bdadbe7fc44414c6d46cdd57e6802
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627512
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Henrik Andreasson <hen...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80429}

[modify] https://crrev.com/fee2336535714a2ee4018f02bcf7e258b1bd8ed8/src/diagnostics/system-jit-win.cc
[modify] https://crrev.com/fee2336535714a2ee4018f02bcf7e258b1bd8ed8/test/unittests/BUILD.gn
[modify] https://crrev.com/fee2336535714a2ee4018f02bcf7e258b1bd8ed8/src/logging/runtime-call-stats.h
[add] https://crrev.com/fee2336535714a2ee4018f02bcf7e258b1bd8ed8/test/unittests/api/v8-script-unittest.cc
[modify] https://crrev.com/fee2336535714a2ee4018f02bcf7e258b1bd8ed8/include/v8-script.h
[modify] https://crrev.com/fee2336535714a2ee4018f02bcf7e258b1bd8ed8/src/api/api.cc
[modify] https://crrev.com/fee2336535714a2ee4018f02bcf7e258b1bd8ed8/src/logging/log.cc

[henr… via monorail]

Updates:
Cc: jdap...@igalia.com surs...@microsoft.com sulek...@microsoft.com

Comment #50 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c50

Listing three remaining issues that I see. It is possible that things are better now given the latest changes but I currently don't have the resources to check. PS, I am not a V8 developer and might use invalid or bad terminology here.

1) Still see many missing stack segments in callstacks based on ETW when profiling more complex JS applications. See e.g. attached figure which comes from https://browserbench.org/Speedometer2.0/. We are able to see complete/full callstacks on Linux but not on Windows.
2) "Truncated JIT-ted functions in ETW". Details have been shared in a separate document.
3) Lack support for WASM events which is essential since most really complex web applications use WASM.

Also adding stakeholders that have shown interest in contributing. IMHO, we need resources and expertise from Microsoft to finalize this implementation and resolve all open issues.

Attachments:
missing_stack_segments.png 584 KB

[jdap… via monorail]

Comment #55 on issue 11043 by jdap...@igalia.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c55

Created the following tickets for tracking the reported issues:
* https://bugs.chromium.org/p/v8/issues/detail?id=12988 - truncated JIT
* https://bugs.chromium.org/p/v8/issues/detail?id=12987 - method names reported to ETW should be improved for clarity
* https://bugs.chromium.org/p/v8/issues/detail?id=12989 - WASM support
* https://bugs.chromium.org/p/v8/issues/detail?id=12990 - missing frames in speedometer 2.0 trace views

[Git Watcher via monorail]

Comment #56 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c56

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/4baf6a2fdebcb01ed34188106f6868aa937bbcb0

commit 4baf6a2fdebcb01ed34188106f6868aa937bbcb0
Author: Suraj Sharma <sur...@microsoft.com>
Date: Fri Jul 22 03:04:16 2022

Separates ETW Stack Walking Events from Generic ETW Events

All ETW Events are controlled by v8_enable_system_instrumentation.
This flag is turned off when perfetto is enabled since traces events
flowing through TRACE_EVENT macros can't be intercepted by Recorder.

Since, stack walking Events don't use TRACE_EVENT it can be turned
back on, when using perfetto. Hence, creating a separate Build Flag
for emitting stack walking event until the recorder is ported.


Bug: v8:11043
Change-Id: I6cdb81400780e54fddf6d6e2476cad29c60483d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704465
Reviewed-by: Toon Verwaest <verw...@chromium.org>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Suraj Sharma <sur...@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81879}

[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/logging/log.h
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/flags/flag-definitions.h
[rename] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/diagnostics/etw-jit-win.h
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/libplatform/tracing/recorder.h
[rename] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/diagnostics/etw-jit-metadata-win.h
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/execution/isolate.cc
[rename] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/diagnostics/etw-jit-win.cc
[add] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/libplatform/etw/etw-provider-win.h
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/libplatform/tracing/recorder-win.cc
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/init/v8.cc
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/d8/d8.cc
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/BUILD.gn
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/api/api.cc
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/DEPS
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/logging/log.cc
[modify] https://crrev.com/4baf6a2fdebcb01ed34188106f6868aa937bbcb0/src/d8/d8.h

[Git Watcher via monorail]

Comment #57 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c57

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/8199d70fd6df14e4ef91f09d1ed59ba51801b5df

commit 8199d70fd6df14e4ef91f09d1ed59ba51801b5df
Author: Paolo Severini <paol...@microsoft.com>
Date: Tue Sep 13 17:29:58 2022

[profiler][etw] Do not enable --interpreted-frames-native-stack with ETW events

When ETW Events are enabled with the --enable-etw-stack-walking flag
we should not also enable the --interpreted-frames-native-stack by
default.
Showing the interpreted frames on the native stack is quite expensive
since it involves mulltiple copies of the interpreter trampolines, and
it's not always necessary to profile JS code, so it should be enabled
when necessary with a separate flag.

Bug: v8:11043
Change-Id: Id2d779e7fcac9b626f9da2e0c77edf9c30f853df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893601
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83229}

[modify] https://crrev.com/8199d70fd6df14e4ef91f09d1ed59ba51801b5df/src/flags/flag-definitions.h

[Git Watcher via monorail]

Comment #58 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c58

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/9a2dd870e5a08298979c79d7df732cdc0b4a59cd

commit 9a2dd870e5a08298979c79d7df732cdc0b4a59cd
Author: Paolo Severini <paol...@microsoft.com>
Date: Wed Sep 21 18:17:57 2022

[profiler][etw] Dynamically turn on/off ETW tracing

Refactor ETW tracing code to make sure ETW tracing sessions is
correctly started/stopped when a ETW controller (like Windows
Performance Recorder) start/stops a tracing session.

The goal is to enable support for ETW tracing by default making sure
that it does not cause any performance regressions.

Bug: v8:11043
Change-Id: I90085183a1c3f4d35ec7e964dbe4b38243aed0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3905922
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Reviewed-by: Jakob Linke <jgr...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83480}

[modify] https://crrev.com/9a2dd870e5a08298979c79d7df732cdc0b4a59cd/src/logging/log.h
[modify] https://crrev.com/9a2dd870e5a08298979c79d7df732cdc0b4a59cd/src/diagnostics/etw-jit-win.cc
[modify] https://crrev.com/9a2dd870e5a08298979c79d7df732cdc0b4a59cd/src/flags/flag-definitions.h
[modify] https://crrev.com/9a2dd870e5a08298979c79d7df732cdc0b4a59cd/src/libplatform/tracing/recorder-win.cc
[modify] https://crrev.com/9a2dd870e5a08298979c79d7df732cdc0b4a59cd/src/init/v8.cc
[modify] https://crrev.com/9a2dd870e5a08298979c79d7df732cdc0b4a59cd/src/diagnostics/etw-jit-win.h
[modify] https://crrev.com/9a2dd870e5a08298979c79d7df732cdc0b4a59cd/src/logging/log.cc

[Git Watcher via monorail]

Comment #59 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c59

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/7aea8bef7624b6fa146dd040d3a498e0dedc6290

commit 7aea8bef7624b6fa146dd040d3a498e0dedc6290
Author: Paolo Severini <paol...@microsoft.com>
Date: Tue Nov 22 22:49:18 2022

[profiler][etw] Reduce initial jank when starting ETW tracing session

When a ETW tracing sessions starts V8 emits events for all already
jitted functions. In very large apps this can cause a noticeable UI
jank. Most of this time is spent re-parsing all already jitted
functions to ensure that the source positions data for these functions
is available. But for ETW events we only need the initial location of
a function, not its full source position data, therefore we should be
able to omit the reparsing.

Bug: v8:11043
Change-Id: I9f1866464fdb8295ca2118de3ab1a72ce6e0f5b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4049920
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Reviewed-by: Thibaud Michaud <thib...@chromium.org>
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84440}

[modify] https://crrev.com/7aea8bef7624b6fa146dd040d3a498e0dedc6290/src/logging/log.h
[modify] https://crrev.com/7aea8bef7624b6fa146dd040d3a498e0dedc6290/src/logging/log.cc

[jdap… via monorail]

Comment #60 on issue 11043 by jdap...@igalia.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c60

I have been doing some benchmarking. For x86-64, the impact of enabling ETW by default is negligible. I see a small overhead for Octane specifically, but that could perfectly be local machine overhead, as all the other numbers I am getting show the impact of enabling by default right now is null or too much small to differenciate. Should we still test in x86-32 or can we just enable it by default now?

(I am attaching the numbers I collected with CSuite).

Attachments:
BB-161_ benchmark of ETW flags.html 8.7 KB

[henr… via monorail]

Comment #61 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c61

Thanks for all the work here. What is the status with e.g. the three issues listed in Comment #50?

[jdap… via monorail]

Comment #62 on issue 11043 by jdap...@igalia.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c62

I think none of them is fixed yet. It is in the backlog and I created tickets for working on each of the issues, but I still did not start any of them. I expect to start working at least on speedometer issues first next week.

[henr… via monorail]

Comment #63 on issue 11043 by hen...@chromium.org: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c63

Many thanks and highly appreciated.

[jdap… via monorail]

Comment #64 on issue 11043 by jdap...@igalia.com: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c64

Conclusion for 32bit is pretty similar. Adding an updated table including 32 bits, where we can see the impact is low or zero. It would be interesting to try enabling by default ETW stack walking soon, so performance bots can tell with deeper analysis if there is an actual regression of any kind.

Attachments:
BB-161_ benchmark of ETW flags.html 8.7 KB

[Git Watcher via monorail]

Comment #65 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c65

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/8c26b5fc1681aefd4c42044caad08a6a4393ff98

commit 8c26b5fc1681aefd4c42044caad08a6a4393ff98
Author: José Dapena Paz <jda...@igalia.com>
Date: Mon May 22 18:39:19 2023

[etw] Dynamically disable code compaction

Instead of disabling code space compaction when ETW stalk walking
is enabled inconditionally, only disable it when ETW recording is
ongoing.

This should help enabling by default ETW stack walking.

Bug: v8:11043
Change-Id: I12a5c21f7de114a1b41d1aafe873e18da8c7fca3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4551044
Reviewed-by: Michael Lippautz <mlip...@chromium.org>

Commit-Queue: José Dapena Paz <jda...@igalia.com>

Cr-Commit-Position: refs/heads/main@{#87838}

[modify] https://crrev.com/8c26b5fc1681aefd4c42044caad08a6a4393ff98/src/logging/code-events.h
[modify] https://crrev.com/8c26b5fc1681aefd4c42044caad08a6a4393ff98/src/execution/isolate.cc
[modify] https://crrev.com/8c26b5fc1681aefd4c42044caad08a6a4393ff98/src/logging/log.h
[modify] https://crrev.com/8c26b5fc1681aefd4c42044caad08a6a4393ff98/src/flags/flag-definitions.h
[modify] https://crrev.com/8c26b5fc1681aefd4c42044caad08a6a4393ff98/src/heap/mark-compact.cc
[modify] https://crrev.com/8c26b5fc1681aefd4c42044caad08a6a4393ff98/src/execution/isolate.h

[Git Watcher via monorail]

Comment #66 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c66

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/ef03ac80c21a9e3d743410935baf8075643bb81d

commit ef03ac80c21a9e3d743410935baf8075643bb81d
Author: Paolo Severini <paol...@microsoft.com>
Date: Tue May 09 22:15:54 2023

[etw] Use Script::GetNameOrSourceURL() to identify scripts in ETW traces

Currently ETW is emitting events using the Script name to identify the
script source. It would be better to use the script source_url instead,
and the script name only when the source_url is undefined.

Bug: v8:11043
Change-Id: Ida00d547df7ff205d3775c05903279b6ba3d4a20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4519117
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87841}

[modify] https://crrev.com/ef03ac80c21a9e3d743410935baf8075643bb81d/src/diagnostics/etw-jit-win.cc

[Git Watcher via monorail]

Comment #67 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c67

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/1287e3c26da2a64a25522885cad877f192f40039

commit 1287e3c26da2a64a25522885cad877f192f40039

Author: José Dapena Paz <jda...@igalia.com>

Date: Tue May 23 16:02:47 2023

[etw] Register code event handler on isolate creation

When d8 starts with ETW recorder enabled, we observed it was not
emiting symbols before a prompt run would happen.

To fix this, in isolate creation, after all the builtins have been
added, we check if if needs to be enabled, so all builtins are
emited.

Bug: v8:11043
Change-Id: Ie67bf3805c9630a0cd4e736d2fe16268e02a3864
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4577223
Reviewed-by: Camillo Bruni <cbr...@chromium.org>

Commit-Queue: José Dapena Paz <jda...@igalia.com>

Reviewed-by: Jakob Linke <jgr...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88303}

[modify] https://crrev.com/1287e3c26da2a64a25522885cad877f192f40039/src/execution/isolate.cc

[Git Watcher via monorail]

Comment #68 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c68

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/758004c2ad79c87b46030a1f3c6bb59938d2d446

commit 758004c2ad79c87b46030a1f3c6bb59938d2d446
Author: Paolo Severini <paol...@microsoft.com>
Date: Tue Aug 08 23:38:14 2023

[etw] Dynamically generate InterpreterEntryTrampoline copies

Instead of generating copies of InterpreterEntryTrampolines when
the --interpreted-frames-native-stack is set inconditionally, only
generate them when some logging (like ETW recording) is ongoing.

This should help enabling by default ETW stack walking.

Bug: v8:11043

Change-Id: I88fee0ee20251fd459888927d0d1c274f38d9326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4678362
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#89460}

[modify] https://crrev.com/758004c2ad79c87b46030a1f3c6bb59938d2d446/test/unittests/test-utils.h
[modify] https://crrev.com/758004c2ad79c87b46030a1f3c6bb59938d2d446/src/logging/log.h
[modify] https://crrev.com/758004c2ad79c87b46030a1f3c6bb59938d2d446/test/unittests/logging/log-unittest.cc
[modify] https://crrev.com/758004c2ad79c87b46030a1f3c6bb59938d2d446/src/codegen/compiler.cc
[modify] https://crrev.com/758004c2ad79c87b46030a1f3c6bb59938d2d446/src/codegen/compiler.h
[modify] https://crrev.com/758004c2ad79c87b46030a1f3c6bb59938d2d446/test/unittests/interpreter/interpreter-unittest.cc
[modify] https://crrev.com/758004c2ad79c87b46030a1f3c6bb59938d2d446/src/logging/log.cc

[Git Watcher via monorail]

Comment #69 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c69

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/eba297a8101cfb6197dd14dfbf547112ad86e958

commit eba297a8101cfb6197dd14dfbf547112ad86e958
Author: Paolo Severini <paol...@microsoft.com>
Date: Mon Aug 21 20:36:53 2023

[profiler][etw] Enables filtering of ETW tracing by URL

Currently, when an ETW tracing session is started, it impacts all
renderer processes. In each renderer V8 emits ETW events to track all
the existing interpreted or jitted functions and for large websites the
emission of this initial burst of events can be relatively expensive.

This change allows to selectively enable ETW by URL, i.e., only on the
isolates that are running in a document that navigates to one of a set
of specified URLs.

Windows allows passing additional data to the ETW EnableCallback
https://learn.microsoft.com/en-us/windows/win32/api/evntprov/nc-evntprov-penablecallback

This data can be configured in a WPR (Windows Performance Recorder)
profile, adding a CustomFilter to an EventProvider like the following:

<EventProvider Id="Edge_Stable" Name="57277741-3638-4A4B-BDBA-0AC6E45DA56C" Level="5">
<CustomFilter Type="0x80000000" Value="AQABAAAAAAA..." />
</EventProvider>

Where:
- Name="57277741-3638-4A4B-BDBA-0AC6E45DA56C" is the GUID of the V8
ETW provider, (see src/libplatform/etw/etw-provider-win.h),
- Type="0x80000000" is EVENT_FILTER_TYPE_SCHEMATIZED,
- Value="AQABAAAAAA..." is a base64-encoded byte array that is
base64-decoded by Windows and passed to the ETW enable callback in
the 'PEVENT_FILTER_DESCRIPTOR FilterData' argument; see:
https://learn.microsoft.com/en-us/windows/win32/api/evntprov/ns-evntprov-event_filter_descriptor.

This array contains a struct EVENT_FILTER_HEADER followed by a
variable length payload, and as payload we pass string in JSON format,
with a list of regular expressions that should match the document URL
in order to enable ETW tracing:
{
"version": "1.0",
"filtered_urls": [
"https:\/\/.*\.chromium\.org\/.*", "https://v8.dev/", "..."
]
}

The actual filtering will be implemented as a callback by the
embedder; see:
https://chromium-review.googlesource.com/c/chromium/src/+/4776268.

Bug: v8:11043
Change-Id: Icee297bec0560fd34b502d693d337cf69b707274
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4775987
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89616}

[modify] https://crrev.com/eba297a8101cfb6197dd14dfbf547112ad86e958/include/v8-isolate.h
[modify] https://crrev.com/eba297a8101cfb6197dd14dfbf547112ad86e958/src/execution/isolate.cc
[modify] https://crrev.com/eba297a8101cfb6197dd14dfbf547112ad86e958/include/v8-callbacks.h
[modify] https://crrev.com/eba297a8101cfb6197dd14dfbf547112ad86e958/src/diagnostics/etw-jit-win.cc
[modify] https://crrev.com/eba297a8101cfb6197dd14dfbf547112ad86e958/src/diagnostics/etw-jit-win.h
[modify] https://crrev.com/eba297a8101cfb6197dd14dfbf547112ad86e958/src/execution/isolate.h
[modify] https://crrev.com/eba297a8101cfb6197dd14dfbf547112ad86e958/src/api/api.cc

[Git Watcher via monorail]

Comment #70 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c70

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src/+/307cd5e428dfbf6dd544077508353f4c3a413bb4

commit 307cd5e428dfbf6dd544077508353f4c3a413bb4
Author: Paolo Severini <paol...@microsoft.com>
Date: Mon Sep 11 14:49:47 2023

[v8][etw] Enables filtering of ETW tracing by URL

Implements a callback function called by v8 to selectively enable ETW
tracing only for a set of URLs specified in a Windows Performance
Recorder profile.
The V8 counterpart is:
https://chromium-review.googlesource.com/c/v8/v8/+/4775987.

Bug: v8:11043
Change-Id: Ied5a011b25c9df8846843fcb4cb3cf5748cb7b59
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4776268
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Reviewed-by: Michael Lippautz <mlip...@chromium.org>
Reviewed-by: Kentaro Hara <har...@chromium.org>
Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1194850}

[modify] https://crrev.com/307cd5e428dfbf6dd544077508353f4c3a413bb4/third_party/blink/renderer/bindings/bindings.gni
[modify] https://crrev.com/307cd5e428dfbf6dd544077508353f4c3a413bb4/third_party/blink/renderer/core/BUILD.gn
[add] https://crrev.com/307cd5e428dfbf6dd544077508353f4c3a413bb4/third_party/blink/renderer/bindings/core/v8/v8_initializer_win.cc
[modify] https://crrev.com/307cd5e428dfbf6dd544077508353f4c3a413bb4/third_party/blink/renderer/bindings/core/v8/v8_initializer.cc
[modify] https://crrev.com/307cd5e428dfbf6dd544077508353f4c3a413bb4/third_party/blink/renderer/bindings/core/v8/DEPS

[Git Watcher via monorail]

Comment #71 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c71

The following revision refers to this bug:

https://chromium.googlesource.com/v8/v8/+/2ef3d07f93f15ff13ad500a7550adaca594931a2

commit 2ef3d07f93f15ff13ad500a7550adaca594931a2
Author: Paolo Severini <paol...@microsoft.com>
Date: Mon Sep 11 15:17:30 2023

[etw] Fix build error with'v8_enable_etw_stack_walking = false'

Bug: v8:11043
Change-Id: I318b76b7d06f6f75c382f7593584d597961235a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4856762

Reviewed-by: Camillo Bruni <cbr...@chromium.org>
Commit-Queue: Paolo Severini <paol...@microsoft.com>

Cr-Commit-Position: refs/heads/main@{#89910}

[modify] https://crrev.com/2ef3d07f93f15ff13ad500a7550adaca594931a2/src/api/api.cc

[Git Watcher via monorail]

Comment #72 on issue 11043 by Git Watcher: ETW Instrumentation
https://bugs.chromium.org/p/v8/issues/detail?id=11043#c72

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src/+/534ab1daba54b54c16732a7ff4b660a6f14ce10b

commit 534ab1daba54b54c16732a7ff4b660a6f14ce10b
Author: Paolo Severini <paol...@microsoft.com>
Date: Tue Oct 24 13:14:50 2023

[profiler][etw] Fix potential crash in FilterETWSessionByURLCallback

In the v8 callback FilterETWSessionByURLCallback used to filter ETW
sessions we use an ExecutionContext* retrieved from a v8::Context, but
we need to handle the case where the ExecutionContext* is null.

Bug: v8:11043
Change-Id: I257982a865f9f5f470041205463b99ac18426607
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4966940
Reviewed-by: Jakob Kummerow <jkum...@chromium.org>
Reviewed-by: Kentaro Hara <har...@chromium.org>
Commit-Queue: Paolo Severini <paol...@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1214130}

[modify] https://crrev.com/534ab1daba54b54c16732a7ff4b660a6f14ce10b/third_party/blink/renderer/bindings/core/v8/v8_initializer_win.cc