There's at least one on that list that's (at least in my experience) gone from relatively mainstream to esoteric - self-modification.
Back in the day when both memory and clock cycles were very precious, it wasn't unknown to use self-modifying code as a performance optimisation trick. I did it at least once in the late 80s, when I was working on comms software that had to be as fast as possible in order to avoid missing incoming data.
There was a check that needed to be done on every byte - I think it was whether I was now processing graphics characters or not - but the check was taking valuable time, and the value didn't change very often.
So the most efficient way I found to do it was to wait until I got a "switch to/from graphics" byte in the input stream and then update the instruction at a given location to either be "unconditional jump to graphics routine" or a "no operation (NOP)", which passed straight through to the routine for normal characters.
It was a horrible hack, but it worked.
Thankfully, I've not felt the need to even consider this approach for the past 20 years.
That eventually turned into JITs, and it's still a very powerful technique for tight loops on modern processors, although the pipeline means the benefit happens with more iterations than on the old non-pipelined/cacheless CPUs. It can even be done across multiple cores, as I coincidentally explained here a short while ago:
I don't think SMC has ever been "relatively mainstream", at least after HLLs gained popularity over Asm. But in Asm, it still has its uses where a full JIT would be far too much overhead.
Very long ago, before index registers were a fancy new feature for the cool kids, one would modify the address fields of load/store instructions in order to stride through memory or traverse a list.
Back in the day when both memory and clock cycles were very precious, it wasn't unknown to use self-modifying code as a performance optimisation trick. I did it at least once in the late 80s, when I was working on comms software that had to be as fast as possible in order to avoid missing incoming data.
There was a check that needed to be done on every byte - I think it was whether I was now processing graphics characters or not - but the check was taking valuable time, and the value didn't change very often.
So the most efficient way I found to do it was to wait until I got a "switch to/from graphics" byte in the input stream and then update the instruction at a given location to either be "unconditional jump to graphics routine" or a "no operation (NOP)", which passed straight through to the routine for normal characters.
It was a horrible hack, but it worked.
Thankfully, I've not felt the need to even consider this approach for the past 20 years.