Content deleted Content added
Guy Harris (talk | contribs) And that's a security issue with allowing code modification, and an example of OS mechanisms to allow it to be less insecure, not an example of how code modification is used in operating systems. |
Guy Harris (talk | contribs) →Interaction of cache and self-modifying code: It's not just some ARM and MIPS cores where that's an issue; HyperSPARC, for example, also had that issue. |
||
Line 162:
==Interaction of cache and self-modifying code==
On architectures without coupled data and instruction cache (for example, some SPARC, ARM, and MIPS cores) the cache synchronization must be explicitly performed by the modifying code (flush data cache and invalidate instruction cache for the modified memory area).
In some cases short sections of self-modifying code execute more slowly on modern processors. This is because a modern processor will usually try to keep blocks of code in its cache memory. Each time the program rewrites a part of itself, the rewritten part must be loaded into the cache again, which results in a slight delay, if the modified [[codelet]] shares the same cache line with the modifying code, as is the case when the modified memory address is located within a few bytes to the one of the modifying code.
| |||