Once we've intercepted the kernel-to-user transfer, we need to handle the reverse transfer -- how is the interrupted application state continued? In some cases, it may not be returned to (e.g., a signal using longjmp() to unwind the stack). A runtime system has additional state beyond the machine context saved by the kernel. If that context may not be returned to, it is best to not carry this state across the kernel control transfer, to avoid a memory leak.

However, for Windows callbacks, the kernel keeps the state for the interrupted application context. If the kernel has state across the transfer, we must also -- since we do not know where the continuation point is, we must not modify the old state so that when the kernel sends control back there everything will work. And since these events can be nested, we need a stack of contexts, to match the kernel's. Furthermore, since we do not know the interruption point, we cannot delete ANY fragment from the code cache, since we may return there!