Some early systems, like TeX and I believe some Lisps, took this to the extreme. Instead of patching, they loaded their config once and then dumped the configured process image to a file, which was used in subsequent invocations.

IIRC early Turbo Pascal versions worked like that too, there was some "setup" program that let you configure colors, etc, by modifying the COM/EXE file itself.

Yep. Even outside of tracing, there are several different ways that the Linux kernel patches itself:

- Static calls: like a call to a global function pointer, except instead of loading a function pointer and doing an indirect call, the code is patched to do a direct call to the destination

- Static keys: like an if statement testing a global boolean, except instead of loading a boolean and doing a conditional branch, the code is patched to do either an unconditional branch or a nop

- Runtime constants: like a load of a global variable, except instead of loading, the value is patched directly into the code

- Alternatives: selects one of multiple possible instruction sequences depending on (usually) whether the CPU supports specific instructions

It's really fascinating to see the kind of fun efficient stuff you can do when you have that level of low-level control. Not just code patching but things like RCU as well.

> However it is still interesting to write machine code snippets once and execute them many times, like the nested function trampolines.

I slightly disagree on this though. In my experience writing code with Clang blocks (which don't use trampolines), they're often useful for code organization even if the callback will only be called once. Therefore, even ignoring security issues, I think GCC choosing a design that required cache flushing was a mistake - certainly in retrospect (as cache flushing has become more expensive over the years), but perhaps even at the time. I did some research, and trampolines were introduced in GCC 2.0, which already included mprotect calls and/or cache flushes on some of the architectures it supported, such as MIPS. However, this was a relatively new development, and on most of the supported architectures it didn't do either of those things. But on MIPS it would do an mprotect every single time a trampoline was created, which can't have been fast.

Modifying a constant in code might make sense because it saves several precious bytes of variable storage.

It's pretty much always beneficial to do something more directly. Doing less work is always better than doing more work. The slowness of modern software is the result of a stack of abstractions acting like a stack of interpreters. You write something in React, that manipulates a React object tree and shadows it to a DOM, which gets shadowed to an internal object tree which gets laid out and shadowed to a stack of GPU layers which gets written out as drawing commands... When you want to scroll up there's so much work to do. To make it fast, cut through layers and minimize work. In the 1990s, scrolling up meant calculating how many pixels to scroll, blitting that many pixels in the main framebuffer (usually GPU accelerated) and then rendering the new pixels at the bottom. There wasn't even a double buffer. Very little abstraction there, just the shortest path to achieve the desired result. The GPU driver did abstract the blit and rendering operations, of course, and the mouse driver abstracted the scrollwheel event, and you may have a wrapper component in your GUI tree that manages a viewport over a larger virtual component, but it's all kept as direct as practical. I can't imagine any electron app using the blit-pixels-up approach.

I remember once learning of a runtime environment that would inline class functions. For example they wrote an OS, and if you had an object of a SATA hard drive class, it would copy the function code and inline the drive ID. I don't remember how well it worked for them.

A related idea is the "tracing JIT". You know how you expect a JIT to translate one function at a time? A tracing JIT doesn't - it follows the program logic wherever it goes, through whatever control flow, and compiles all of it until it decides to stop. The most well known implementation is probably LuaJIT.

It’s not a question of ISA support. If you call via a function pointer, how do you supply the pointer to the data? (It has to either be in a separate place from the function code, or the same place. One requires an ABI change, the other an executable, writable section of memory.)