[release/11.0-preview4] High-performance EventSource runtime async profiler.

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4

[hoyosjs]

Motivation

TPL includes support to capture compiler async (AsyncV1) events to stitch together async callstacks in tools like PerfView, VS .NET Async Profiler, and Application Insights Profiler.

The challenge using TPL events profiling async-heavy workloads is that they are verbose and produce a lot of data, creating too much overhead on the profiled process and skewing measurements.

Each TPL event is written into ETW/EventPipe/UserEvents causing latency (kernel call) as well as additional data (~100-byte header). Even a small event without a stack takes 200–500 ns to emit at 100+ bytes. TPL tracking of async execution generates heavy traffic on the eventing subsystem, increasing the risk of dropping events.

TPL overhead (synthetic benchmark)

Async resume/suspend rate	Throughput drop	ETL size (20 s)	Dropped events
1M/s	>75%		severe (requires enlarged ETW buffers)
100K/s	~45%	3+ GB	high (requires enlarged ETW buffers)
10K/s	~10%		moderate

TPL depends on a complete chain of events to recreate async callstacks — losing any events makes post-processing unreliable.

There have been ideas for quite some time to look into a more lightweight approach to track async method execution, making it possible to recreate async callstacks for sync callstacks captured by external tools like OS CPU samplers and profilers.

With the introduction of runtime async (AsyncV2), it was decided to revisit this and see what we could do to improve the profiler experience of async code. The async profiler is not tied to runtime async methods (AsyncV2), so it will be able to handle compiler async methods (AsyncV1) as well, but this PR focuses on AsyncV2. Follow-up PRs will add AsyncV1 support, making it possible to use the new async profiler to collect both AsyncV1 and AsyncV2 async callstacks.

---

Design

NOTE: All formats introduced by this PR are currently considered internal and can be changed without notice.

This PR adds AsyncProfilerBufferedEventSource — a high-performance EventSource for async method profiling that uses per-thread buffered event emission with centralized flush coordination.

Core architecture

• Per-thread event buffers with lock-free acquire/release for zero-contention writes on the hot path.
• Delta timestamp encoding using compressed variable-length integers (LEB128 + zigzag), reducing per-event timestamp overhead from 8 bytes to typically 1–2 bytes under load.
• Delta IP encoding using compressed variable-length integers, reducing bytes per frame IP.
• Centralized AsyncThreadContextCache with background flush timer for idle and dead thread buffer reclamation.
• Continuation wrapper table for compact async callstack representation, mapping runtime IPs to table indices — enables matching sync callstacks captured by OS CPU profilers through the resume async callstack event.

Event types

Events cover the full async lifecycle:

Category	Events
Async context	create, resume, suspend, complete
Async method	resume, complete
Exception unwind	unhandled, handled
Async callstacks	create, resume, suspend

Buffer management

• Configurable buffer size via DOTNET_AsyncProfilerEventSource_EventBufferSize (default 16 KB − 256 bytes).
• Optimized buffer serialization with low overhead.
• SyncPoint mechanism for coordinated config changes across writer threads.
• BlockContext flag for safe flush-thread access to live thread buffers with 100 ms spin timeout to prevent flush thread stalls.

Integration

• Async profiler wired into AsyncInstrumentation alongside the async debugger.
• Cross-runtime design: EventSource + AsyncProfiler with CoreCLR-specific parts in a dedicated source file.

Test coverage

Comprehensive test suite (AsyncProfilerTests) validating event correctness, buffer serialization, delta encoding, callstack capture, config changes, and multi-threaded stress scenarios.

---

Performance results

Overhead comparison: async profiler vs. TPL

Async resume/suspend rate	TPL overhead	Async profiler overhead	Improvement
1M/s	>75%	~20%	~4×
100K/s	~45%	<1%	~40×
10K/s	~10%	<0.3% (noise)	~30×

Note: The 1M/s scenario is extreme — the benchmark does virtually no work, only exercising the internal async dispatch loop. Any real user code in the async methods will quickly reduce the relative overhead.

Data volume

ETL file size is down ~10× for scenarios capturing data to recreate async callstacks. For the 1M/s scenario over 20 seconds:

	ETL size	Dropped events
TPL	3+ GB	many (default ETW settings)
Async profiler	~330 MB	none (default ETW settings)

VS CPU profiling visibility

Running the 1M/s scenario under VS CPU profiling, none of the async profiler methods stand out — most are in the 0.01–0.03% self-CPU range with very low sample counts. The instrumented DispatchContinuations function shows ~2% overhead compared to the uninstrumented version. Even in very heavy async workloads, the async profiler does not pollute VS CPU profiling output.

---

Continuation wrapper optimization

My initial ambition was to track the async callstack on any thread at any point using a single event including the resumed async callstack executed through the dispatch loop. Initially that strategy hit issues due to ambiguity mapping methods between sync callstacks collected by the OS CPU sampler and the resumed async callstack active at that time.

This can be solved using CompleteAsyncMethod events to recreate async callstacks at any point in time. CompleteAsyncMethod is just a signal event consuming a couple of bytes in the event buffer, but it introduces ~30–40 ns per completed method. The major cost is capturing the QPC (~15–20 ns, platform-dependent); the rest is raw memcpy + delta encoding. Reading the timestamp directly via CPU instruction could bring this down to ~10 ns total — a potential future optimization (would require a JIT intrinsic).

Instead of continuing to optimize CompleteAsyncMethod, I revisited the original problem: if we inject an anchor in the sync callstack captured by external tools, we can use it to tie into the async callstack emitted via the resume async callstack event. Since we control the dispatch loop running each continuation, it's possible to call through an indexed wrapper that places enough information in the sync callstack to identify the current resumed continuation.

With up to 255 frames in an async callstack, the pre-generated wrappers are capped at 32 and recycled, emitting a reset event into the stream to signal reuse to parsers. This mechanism makes it possible to recreate any async callstack tied to sync callstacks captured by external tools using a single event (ResumeAsyncCallstack).

Calling through the wrapper costs ~5 ns per method resume — compared to ~30–40 ns for CompleteAsyncMethod plus increased output size, this ended up as a very successful optimization.

---

Timestamp correlation

All async profiler events are emitted using existing EventSource infrastructure, meaning it's possible to listen on the event stream using in-proc EventListeners, ICorProfiler, as well as external ETW/EventPipe/UserEvent clients.

When events are used to recreate async callstacks for other events capturing sync callstacks emitted into the same event subsystem, all events share the same timestamp infrastructure. If events are emitted using different timestamp infrastructure not in sync, timestamps need to be re-synchronized and adjusted before use.

Each buffered event uses the machine's QPC infrastructure (Stopwatch.GetTimestamp), and each event buffer includes the timestamp of first and last event. The metadata event emitted at the beginning of the stream includes a reference QPC + QPC frequency + reference UTC time in ticks, making it possible to convert all buffered events to wall clock time. Every minute, a clock sync event is emitted into the stream re-syncing QPC and UTC time.

---

Future work

• AsyncV1 support will come as follow-up PR(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR introduces a new high-performance runtime async profiler pipeline based on a buffered EventSource, integrates it into the CoreCLR runtime-async (AsyncV2) dispatch path, and adds a comprehensive validation test suite for the emitted buffered event format and behaviors.

Changes:

• Adds AsyncProfilerEventSource + AsyncProfiler implementation in System.Private.CoreLib to emit per-thread buffered async lifecycle/callstack events with centralized flushing.
• Integrates async-profiler instrumentation into CoreCLR’s runtime-async dispatcher (including continuation-wrapper IP table support for correlating with native CPU samples).
• Adds/updates tests in System.Threading.Tasks.Tests to validate event buffer format, delta encoding, callstack semantics, timer flush behavior, and instrumentation flag synchronization.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Threading.Tasks.Tests.csproj	Adds the new AsyncProfilerTests.cs compilation unit (non-mono).
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/RuntimeAsyncTests.cs	Updates debugger attach/detach simulation to use the new “Synchronize” bit behavior; removes interpreter ActiveIssue skips.
src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerTests.cs	Adds extensive tests for async-profiler buffered event emission, parsing, ordering, flushing, and wrapper IP metadata.
src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TplEventSource.cs	Removes prior async-instrumentation flag toggling from OnEventCommand.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfilerEventSource.cs	Adds the new EventSource that publishes buffered async-profiler payloads and handles flush/config commands.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.cs	Adds the managed async-profiler core: buffering, serialization, config, and thread-context cache/flush coordination.
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncInstrumentation.cs	Reworks flag synchronization semantics (renames “Uninitialized” to “Synchronize” and changes sync logic).
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Includes new async-profiler sources and conditions out async instrumentation for Mono builds.
src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestUtilities.cs	Excludes the new async-profiler EventSource from “no EventSources running” assertions.
src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj	Adds CoreCLR-specific async-profiler implementation file to the build.
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncProfiler.CoreCLR.cs	Adds CoreCLR-specific profiler pieces: runtime callstack capture and continuation-wrapper table (32 wrappers).
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Wires async-profiler hooks into runtime-async dispatch and extends AsyncDispatcherInfo to carry profiler state.
src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj	Adds CoreCLR async-profiler CoreCLR-partition source to NativeAOT corelib build.

[Copilot]

Assembly.GetType(...) and Type.GetMethod(...) return nullable types. Assigning them to non-nullable Type/MethodInfo will trigger nullable warnings (and can become build breaks if warnings are treated as errors). Consider declaring these as Type? / MethodInfo? (or using null-forgiving only after the null check) so the nullability matches the APIs and the subsequent Assert.NotNull / Assert.True(method is not null, ...) validations.

Suggested change

	TypecwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfomethod=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method.MethodHandle);
	Type?cwType=typeof(object).Assembly.GetType("System.Runtime.CompilerServices.AsyncProfiler+ContinuationWrapper");
	Assert.NotNull(cwType);
	for(inti=0;i<wrapperIPs.Length;i++)
	{
	stringexpectedName=$"Continuation_Wrapper_{i}";
	MethodInfo?method=cwType.GetMethod(expectedName,BindingFlags.NonPublic|BindingFlags.Static);
	Assert.True(methodis not null,$"Expected method '{expectedName}' to exist on ContinuationWrapper type");
	System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(method!.MethodHandle);

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

Config.Update copies eventKeywords directly into ActiveEventKeywords. In EventSource, a matchAnyKeyword value of 0 is a special case meaning “all keywords”, but with the current logic ActiveEventKeywords == 0 causes IsEnabled.AnyAsyncEvents / per-event keyword checks to evaluate false and disables the profiler even when the EventSource is enabled without an explicit keyword mask. Consider normalizing eventKeywords == 0 to AsyncEventKeywords (or otherwise honoring the EventSource ‘0 means all’ semantics) before computing ActiveEventKeywords / updating flags.

Suggested change

	ActiveEventKeywords=eventKeywords;
	ActiveEventKeywords=eventKeywords==0?AsyncEventKeywords:eventKeywords;

[Copilot]

FlushCore reads context.LastEventTimestamp without any atomic/volatile read. On 32-bit platforms, long reads can tear, which could lead to spurious large values (skipping needed flushes indefinitely) or small values (premature flush/reclaim). Since this is a background path, consider using Volatile.Read(ref context.LastEventTimestamp) (and Volatile.Write where it’s updated, if needed) to ensure atomicity across architectures.

Suggested change

	// Read LastEventTimestamp without atomics, could cause teared reads but not critical.
	longlastEventWriteTimestamp=context.LastEventTimestamp;
	// Read LastEventTimestamp atomically to avoid torn 64-bit reads on 32-bit platforms.
	longlastEventWriteTimestamp=Volatile.Read(refcontext.LastEventTimestamp);

[hoyosjs]

Backport of #127238 - but decided this is too risky for p4