Repository navigation
Evaluate profiler callback behavior for runtime async methods #122488
Description
The "enter" callback is currently emitted as part of the prolog, and that means we are calling it also when we resume. On the other hand we do not call the "leave" callback on suspension, so this is inconsistent.
There is a question if we should do the callbacks for suspend and resume or only when starting/finishing. The former means that we won't have arguments/return value available, while the latter means that the events won't be scoped around CPU execution of the method (we could suspend for an indefinite amount of time before seeing the leave callback).
Alternatively we could also just not do these callbacks at all for runtime async methods, or introduce new callbacks for this case.
cc @dotnet/dotnet-diag-contrib -- thoughts?
Activity
[-]JIT: evaluate profiler callbacks for runtime async methods[/-][+]Evaluate profiler callback behavior for runtime async methods[/+]dotnet-policy-service commentedon Dec 12, 2025
Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.
lateralusX commentedon Dec 15, 2025
I have some initial thoughts, but I need to look deeper into this as part of enhancing the async profiling scenarios and discuss more with diagnostic team.
First, I assume current AsyncV1 state machine methods will be instrumented as regular methods meaning you get enter/leave/tail pairs on each invocation of MoveNext method. If we would like to have consistent behavior between AsyncV1/AsyncV2 regarding enter/leave/tail instrumentation, then I believe we should have similar behavior for AsyncV2.
Second, I know VS instrumentation profiler does ReJIT instrumentation of AsyncV1 methods to better track async execution. I will investigate exactly what they currently instrument but feels like adding new profiler callbacks to track AsyncV2 execution, similar to what VS currently in their ReJIT instrumentation of AsyncV1 methods, is probably a good path forward, reducing need to leverage ReJIT profiling to track async execution.
Third, we will need to emit some events around AsyncV2 execution (TPL/TPL-Lite scenarios) that probably is close to VS instrumentation points mentioned above. Some areas of interest (AsyncV1 track most of this as well), when we detect async suspension, when we finalize the suspension and context switch or completed inline and continue sync execution, when we reschedule an async continuation chain on a thread, completion of individual continuations and begin/end around await calls. I believe some of these could be emitted in managed code (like we do for AsyncV1) but haven't looked into all the details yet so any hints or clues on good locations firing these events would be much appreciated.