I would rename it to "Stack walking in C and similar languages" or if you want to be extra pedantic, "Stack walking, but not the GC kind, in classic C implementations" or something like that.
- JVMs have super sophisticated tech to walk the stack. VMs in general rely on the producer of the metadata (the JIT) being in the same process as the consumer (the stack walker), which allows for the approach to change more fluidly as the VM evolves.
- JavaScript VMs also have their own, sophisticated ways to do this.
- If you're walking the stack for GC, then none of this applies to you. You're either not in C, or you're in C and you're using conservative walking, or you're using Henderson frames, or if you're clever, you're using Pizderson frames.
Also, even if you are in C++, there's a lot more to learn, since there are different ABIs for exception handling (the Itanium one that most people use, a different one used by MS, and yet another one if you're on ARM).
Cool article!
I would rename it to "Stack walking in C and similar languages" or if you want to be extra pedantic, "Stack walking, but not the GC kind, in classic C implementations" or something like that.
- JVMs have super sophisticated tech to walk the stack. VMs in general rely on the producer of the metadata (the JIT) being in the same process as the consumer (the stack walker), which allows for the approach to change more fluidly as the VM evolves.
- JavaScript VMs also have their own, sophisticated ways to do this.
- If you're walking the stack for GC, then none of this applies to you. You're either not in C, or you're in C and you're using conservative walking, or you're using Henderson frames, or if you're clever, you're using Pizderson frames.
Also, even if you are in C++, there's a lot more to learn, since there are different ABIs for exception handling (the Itanium one that most people use, a different one used by MS, and yet another one if you're on ARM).