unless we relax the consistency model. If we use weak consistency and assume the application is properly synchronized, we can delay the actual deletion of fragments. At the time of the write, the target fragments are unlinked, but not deleted until all threads have exited the code cache at least once, so we can be sure no one is inside of a to-be-deleted fragment.

Since we've unlinked and removed any loops, the only problem is if there is legitimate synchronization inside the target fragment. If we break fragments at bus locks and system calls, and don't allow traces to bridge compiled code modules and generated code regions, the only case left is quite pathological, involving a condition code check in generated code and a jump to modified code all on a frequently executed path that was inlined into a trace. We have never encountered this.