The final rule applies to things that must be changed in order to efficiently implement an in-process runtime code manipulator. We need to pretend as much as possible that we haven't changed anything. For example, we need to pretend that we're executing original application code rather than a copy. Address transparency is an important part of this.

We're executing copies of application code out of a cache, but from rule 2 we want application data to remain unchanged. Application data includes program addresses. We want these to continue to point to their original native values. The most important reason is that it's not easy to identify which data are stored addresses. To implement this charade, we need to translate addresses in two directions: for an indirect branch, we need to figure out the cache address being referred to; and, for cases where machine contexts are obtained, we need to pretend we were never inside the code cache. This is a lot of work, and as we saw earlier, a significant component of our runtime overhead -- but it's necessary.

I'm going to spend time now on an important aspect of transparency for any code cache system: code cache consistency.