Create TracingMode#53035
Closed
hoxyq wants to merge 11 commits into
Closed
Conversation
meta-cla
Bot
added
the
CLA Signed
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D79557790 |
Summary:
# Changelog: [Internal]
The current design for Tracing is flawed. Right now the logic is mostly scattered around CDP Agents, lifetime of which is tied to CDP session.
This diff introduces a new approach:
- The HostTarget will be the only public entrypoints to startTracing as part of the jsinspector backend.
- It will create and own TraceRecording that acts as a local session. We won't use wording session here, because it is already reserved for CDP case.
- Every Target will implement TracingAgent, lifetime of which will be limited by lifetime of either Target or TraceRecording.
- All these TracingAgent will have a reference to TraceRecordingState, which they can mutate
This approach unblocks:
- Recording traces without active CDP sessions, for example in a background.
- Recording full instance reloads and multiple profiles for Instances and Runtimes.
{F1980838032}
Differential Revision: D79371359
Summary: # Changelog: [Internal] Now that we've defined all actors and relationship between Agents, we can start recording profiles and store them on a recording state. Differential Revision: D79415396
Summary: # Changelog: [Internal] We are deprecating previous `InstanceTarcingProfile` struct, but not removing yet, since this is still used and we will migrate in one of the diffs at the top of the stack. The `InstanceTracingProfile` will consist only of Trace Events that were captured by PerformanceTracer, and will not store Runtime Sampling Profiles. There are multiple reasons for this: 1. As of right now, Runtime Sampling Profiles are completely independant from Instance Profiles and do not require anythings from Instance as a Target to be represented on a timeline. 2. Although PerformanceTracer is a singleton, it should be this way. It captures events for something that can only be dispatched if there is an allocated React Instance, so in the future PerformanceTracer could become a data-member of InstanceTarget. Differential Revision: D79433498
Summary: # Changelog: [Internal] We would need this to correctly serialize Runtime Sampling Profiles. Differential Revision: D79433501
Summary: # Changelog: [Internal] We would need this to correctly serialize Runtime Sampling Profiles. In case of recording the trace in the background, this might not be the value we would want to use, we would probably add another field or calculate it dynamically, depending on the tracing mode. This is not the case for now, will be solved separately on top of the stack. Differential Revision: D79433502
Summary: # Changelog: [Internal] Now TraceRecordingState should capture everything we need in order to display a trace on a timeline. We just need to serialize it properly into collection of serialized Trace Events that would be sent via `Tracing.dataCollected` CDP events. This is what this serializer is doing. Differential Revision: D79434655
Summary: # Changelog: [Internal] CDP Agents should interact with Targets by using Controllers: https://www.internalfb.com/code/fbsource/[0b20b752c43f]/xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern/HostTarget.h?lines=300-303 This diff adds public endpoinst for controlling the trace recording on a `HostTargetController` that will be used by `TracingAgent` later. Differential Revision: D79433500
Summary: # Changelog: [Internal] Now that we've implemented all required serializers and TraceRecordedState has everything needed, we can migrate TracingAgent to use this new infra. Differential Revision: D79433497
Summary: # Changelog: [Internal] Differential Revision: D79434656
Summary: # Changelog: [Internal] We never call `stopTracing()` on a HostTarget, if the Agent was destroyed. This could only happen if the session was destroyed. There could me multiple sessions, so we have to keep the source of truth for recording status in a session state. Differential Revision: D79435494
Summary: Pull Request resolved: facebook#53035 # Changelog: [Internal] This adds an ability to distinguish different trace recordings, based on mode Reviewed By: sbuggay Differential Revision: D79557790
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D79557790 |
Contributor
|
This pull request has been merged in f66ef53. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Changelog: [Internal]
This adds an ability to distinguish different trace recordings, based on mode
Differential Revision: D79557790