You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The notion of tracing JITs definitely predated calling them tracing JIT compilers. See my PhD for my own bad name (lazy recursion detection, what was I thinking): https://apt.cs.manchester.ac.uk/ftp/pub/apt/theses/IanRogers_PhD.pdf For method JITs I think it is important to mention uncommon traps, code that has never been executed is uncommon and so you trap and deoptimize into the interpreter, much as you'd exit a trace to an interpreter. Further off in the weeds, I think the approach of JITs like jython, just creating a trace of bytecode calls to the interpreter functions, look a lot like a kind of directed meta-tracing. It was a sad day when the Java class file format was changed to mandate stack frame maps, as the ability to easily JIT blobs of bytecode was a significant feature. In 2008 I gave a presentation on my first visit to the bay area to the Mozilla TraceMonkey folks advocating against traces, primarily as you should work the best you can with the branch prediction hardware. There were proposed MSc projects for an interpreter in Jikes RVM that would do something like meta JIT compilation as a replacement for the baseline compiler. Some of the people who worked in that area overlapped with Maxine, Graal and Truffle. I think often the invention of names is taken as meaning an idea was created at the same time. Certainly for tracing this isn't true, perhaps had the term hyperblock been more popular we'd be using that - although I always mentally link hyperblocks with Itanium.
Musings on Tracing in PyPy | PyPy
https://www.pypy.org/posts/2025/01/musings-tracing.html
The text was updated successfully, but these errors were encountered: