4 ms·
All JITs use self-modifying code, and JITs are more popular now than even 15 years ago. Although you might make a distinction between modifying code that has al
by cwzwarich 4y ago
All JITs use self-modifying code, and JITs are more popular now than even 15 years ago. Although you might make a distinction between modifying code that has already executed once, from the perspective of instruction/data consistency on a CPU it doesn’t really matter.
- Jensson 4y agoJIT doesn't modify the behavior though, it typically just changes a function pointer and then that function does the same thing but more optimized. So then instruction caches just has some effect on performance instead of changing program behavior.
- cwzwarich 4y agoJITs also modify the code at the destination of the function pointer, which was likely also code at a different time (since it usually needs to be allocated from a separate heap that is marked executable). If the CPU prefetched/cached the instructions at the function pointer target prior to the modification, then the program would observe incorrect behavior, even though it's not self-modifying code in the usual sense.
- miohtama 4y agoSelf-modifying code in a traditional sense has been changing constants and instructions in a tight loops that are assembled by hand. I don't think any of JITs take this approach, as when they emit machine code it is always a fresh memory allocation and fresh compilation. JITs don't "poke and peek" already compiled code. But I could be wrong as JITs are getting complex today.
- ridiculous_fish 4y agoJITs do indeed modify already-compiled code. For example, JavaScriptCore has a notion of a "patchable jump." These are jump instructions intended to be modified later. They may initially point to slow paths, and are later patched to point to faster paths as type information accumulates. https://webkit.org/blog/10298/inline-caching-delete/ https://webkit.org/blog/10298/inline-caching-delete/
- miohtama 4y agoThis looks super interesting, thank you.