JIT: remove dependence on GetThreadCycles #114290
Conversation
and hence on pal-provided QueryThreadCycleTime. Use QueryPerformanceCounter/Frequency instead. This should be good enough for this feature (considering it exists only under DEBUG). Fixes dotnet#105472
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
| bool b = CycleTimer::GetThreadCyclesS(&m_compCyclesAtEndOfInlining); | ||
| if (!b) | ||
| LARGE_INTEGER lpCycles; | ||
| BOOL result = QueryPerformanceCounter(&lpCycles); |
There was a problem hiding this comment.
If QueryPerformanceCounter fails (i.e. result is not TRUE), there is no fallback mechanism (e.g. using GetTickCount as before), which may lead to m_compCyclesAtEndOfInlining remaining uninitialized. Consider adding a fallback to ensure a value is recorded.
Copilot uses AI. Check for mistakes.
There was a problem hiding this comment.
This API is documented to never fail, so we could just ignore the result.
There was a problem hiding this comment.
Looks like the pal version still might fail. Though perhaps this never happens in practice. I'll leave this as is for now.
| { | ||
| return; // We don't have a thread cycle counter. | ||
| if ((int64_t)lpCycles.QuadPart > m_compCyclesAtEndOfInlining) |
There was a problem hiding this comment.
The current logic only updates m_compCycles when the new performance counter value exceeds m_compCyclesAtEndOfInlining. It may be beneficial to explicitly handle or log cases where this condition fails to avoid inadvertently reporting a zero elapsed time.
Copilot uses AI. Check for mistakes.
|
@dotnet/jit-contrib PTAL Arguably we should go farther and remove the uses from SPMI too, and then the PAL support... |
and hence on pal-provided QueryThreadCycleTime.
Use QueryPerformanceCounter/Frequency instead. This should be good enough for this feature (considering it exists only under DEBUG).
Fixes #105472