Context

V8 is migrating to modern events in https://issues.chromium.org/issues/498378089. The CPU profiler emits Profile and ProfileChunk events under the disabled-by-default-v8.cpu_profiler category, which currently use the legacy TRACE_EVENT_SAMPLE_WITH_ID1 macro (phase 'P').

The modern TrackEvent.Type has no TYPE_SAMPLE.

Current plan is to use TRACE_EVENT_INSTANT https://chromium-review.googlesource.com/c/v8/v8/+/7787230/5/src/profiler/profile-generator.cc since a sample event is structurally similar to instant event with a differentiating phase byte.

// Legacy (phase 'P'):
TrackEvent {
  legacy_event {
    phase: 'P'
    unscoped_id: 42
  }
  debug_annotation { ... } ← JSON payload
}

// Modern (TYPE_INSTANT):
TrackEvent {
  type: TYPE_INSTANT
  name: "Profile"
  debug_annotation {       ← JSON payload (same format)
    name: "data"
    string_value: "{...\"id\":42...}"  ← id is HERE (or in correlation_id)
  }
}

Current state in the Perfetto trace processor

Tokenizer

The tokenizer special-cases V8 CPU samples at

Event importer

Phase 'P' has no dedicated case in the phase switch

The problem

Using TYPE_INSTANT there's no way to distinguish a "regular" instant event from a CPU profile sample event at the proto level. The tokenizer must now match by event name ("Profile", "ProfileChunk") rather than by type. Similarly, DevTools must explicitly exclude these events from generic instant event handling, https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/7800921.

1. Should TYPE_INSTANT be the recommended modern replacement for phase 'P'?

The current approach works but requires name-based detection in the tokenizer and explicit exclusions in consumers. As part of this migration, I would need to special case tokenizer like

if (event.type() == TYPE_INSTANT) {
    if (name == "Profile" || name == "ProfileChunk") {
        TokenizeModernSampleEvent(...);
    }
}

Note: TokenizeModernSampleEvent will be using TrackEvent::Decoder instead of LegacyEvent::Decoder rest of the mechanics from the current tokenizer will remain the same.

2. Would a dedicated TYPE_SAMPLE be considered?

   Adding TYPE_SAMPLE to the TrackEvent.Type enum would:

• Allow the tokenizer to continue to detect CPU profile events by type alone
• Eliminate the need for downstream consumers (DevTools) to special-case instant events by name

cc @camillobruni