From 25976c57b0eeafa2dd8a16945a298e29dc1695d4 Mon Sep 17 00:00:00 2001 From: Vance Morrison Date: Wed, 30 Nov 2016 11:45:17 -0800 Subject: [PATCH] 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 --- src/coreclr/src/vm/codeman.cpp | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/coreclr/src/vm/codeman.cpp b/src/coreclr/src/vm/codeman.cpp index cffe191..74fde49 100644 --- 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) -- 2.7.4