Fix to avoid stalling the process when ETW is doing a rundown (dotnet/coreclr#8357)

This only matters when there are MANY JIT compiled methods, but Bing operates
in exactly this mode, and thus it stalls for several seconds while rundown completes.

This fix does not fix the problem completely, but it makes it MUCH less likely, and is
a trivial, safe fix. The problem is that as part of a GC, we do cleanup of any removed
JIT code. To do this we take a JIT code manager lock, but this is also a lock that the
JIT code iterator takes and is used during ETW rundown. Thus rundown blocks GCs.

Almost all the time, we DON'T have JIT code manager cleanup to do, so we just avoid
taking the lock in that case, and this makes the stall MUCH less likely.

Commit migrated from https://github.com/dotnet/coreclr/commit/e26e3551994fd89f9360da7a463628cb7dbe67c5

diff --git a/src/coreclr/src/vm/codeman.cpp b/src/coreclr/src/vm/codeman.cpp
index cffe191..74fde49 100644 (file)
--- a/src/coreclr/src/vm/codeman.cpp
+++ b/src/coreclr/src/vm/codeman.cpp
@@ -3447,6 +3447,16 @@ void EEJitManager::CleanupCodeHeaps()
 
     _ASSERTE (g_fProcessDetach || (GCHeapUtilities::IsGCInProgress() && ::IsGCThread()));
 
+       // Quick out, don't even take the lock if we have not cleanup to do.
+       // This is important because ETW takes the CodeHeapLock when it is doing
+       // rundown, and if there are many JIT compiled methods, this can take a while.
+       // Because cleanup is called synchronously before a GC, this means GCs get
+       // blocked while ETW is doing rundown.   By not taking the lock we avoid
+       // this stall most of the time since cleanup is rare, and ETW rundown is rare
+       // the likelihood of both is very very rare.   
+       if (m_cleanupList == NULL)
+               return;
+
     CrstHolder ch(&m_CodeHeapCritSec);
 
     if (m_cleanupList == NULL)