10 ms·
While bears a significant resemblance, Ertl and Gregg's approach is not automatic and every additional architecture requires a significant understanding of the
by lifthrasiir 3y ago
While bears a significant resemblance, Ertl and Gregg's approach is not automatic and every additional architecture requires a significant understanding of the target architecture---including an ability to ensure that fully relocable code can be generated and extracted. In comparison, the copy-and-patch approach can be thought as a simple dynamic linker, and objects generated by unmodified C compilers are far more predictable and need much less architecture-specific information for linking.
- vanderZwan 3y agoDoes Ertl and Gregg's approach have any "upsides" over copy-and-patch? Or is it a case of just missing those one or two insights (or technologies) that make the whole thing a lot simpler to implement?
- lifthrasiir 3y agoI think so, but I can't say this any more confident until I get an actual copy of their paper (I used other review papers to get the main idea instead).
- pierrebai 3y agoThe copy-and-patch also assumes the compiler will generate patchable code. For example, on some architecture, have a zero operand might have a smaller or different opcode compared to a more general operand. Same issue for relative jumps or offset ranges. It seems the main difference is that the patch approach also patches jumps to absolute addresses instead of requiring instruction-counter relative code.
- naasking 3y agoFull copy of the paper: https://www2.cs.arizona.edu/~collberg/Teaching/553/2011/Resources/jit.pdf https://www2.cs.arizona.edu/~collberg/Teaching/553/2011/Reso... There's also this which seems to use the same technique: Templates-based portable just-in-time compiler, https://dl.acm.org/doi/abs/10.1145/944579.944588 https://dl.acm.org/doi/abs/10.1145/944579.944588 Nice to see there's still room for innovation in the VM space!