Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Commit

Permalink
Fix to avoid stalling the process when ETW is doing a rundown (#8357)
Browse files Browse the repository at this point in the history
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.
  • Loading branch information
vancem authored and jkotas committed Nov 30, 2016
1 parent 0dca898 commit e26e355
Showing 1 changed file with 10 additions and 0 deletions.
10 changes: 10 additions & 0 deletions src/vm/codeman.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down

0 comments on commit e26e355

Please sign in to comment.