Fix for possible false-positive GC delays

[ntovas]

In the application of our organization, we noticed sporadically some .NET Runtime Platform stalled for... warnings, even with very small GC object counts, so after a code review we suspect that the additional checks in WatchdogHeartbeatTick may be responsible for a false-positive GC delay.

Microsoft Reviewers: Open in CodeFlow

[ReubenBond]

These two threads have the same name but different behavior.

[ntovas]

Changed that, thanks.

[ReubenBond]

This seems ok to me, but I would rather it be refactored to still use a single thread, just accounting for the time spend checking other participants. Eg, by extending the try-finally block surrounding CheckYourOwnHealth to cover the entire WatchdogHeartbeatTick() method or by moving the block outside WatchdogHeartbeatTick and into a finally block in Run() instead.

EDIT: by the way, I welcome the gist of the change: reducing false-positive warnings.

[ntovas]

I believe that by using a single thread and delay the next check, we may cause false negatives, and since we already faced a lot of challenges by GC pressure and thread starvation, we would like this check to be as reliable as possible.

[ReubenBond]

GCMonitor is a misnomer, since it is monitoring for execution stalls in general. Maybe call it StallMonitor or RuntimeMonitor