Hacker News Reader

Comment by cwzwarich | Hacker News Reader

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.

View on HN

Self-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.

JITs 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/

This looks super interesting, thank you.

JIT 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.

JITs 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.

Reply on news.ycombinator.com