Our code cache must be kept consistent with the original application code. The issues here are not limited to self-modifying code -- desktop applications load and unload libraries all the time, and if one ever occupies the same address range as a previous library, the original code must be invalidated in the code cache. We've also seen races where the application will target a library after it's been unloaded, resulting in an exception that is caught and handled -- to duplicate that behavior we must invalidate memory at the unload point.

Another example is a trampoline for nested function closures -- which are often kept on the stack. As the stack unwinds and comes back, a second trampoline could be placed at the same address. And of course dynamically generated code can re-use the same memory region for different pieces of code. Here I show the number of cache consistency events in our Office benchmarks.