feat(blog): Add tracing paper blog #527
Conversation
Signed-off-by: Ethan Uppal <[email protected]>
There was a problem hiding this comment.
Hi, Ethan and Tean—thanks for getting this started. I like the points that you have made here (with one exception where I think you've mischaracterized the technical contribution).
However, you're right that this post is very short. It just doesn't say much about the paper yet! I don't think you should add back more background; you probably have enough of that already. But surely you have more thoughts about the paper that you can include—or if you don't, maybe you can steal some from the discussion thread? It seems like there were a lot of opinions, extrapolations, etc. that came up during class, and the idea here is to convey some of that thinking. Can you think of anything else interesting to relate about this paper?
| Ethan Uppal Cornell CS '27 | ||
| Tean Lai Cornell CS '26 |
There was a problem hiding this comment.
This is the place where you're supposed to include some brief information about yourself, maybe some links, etc. Like this:
| name = "Ethan Uppal" | ||
| +++ | ||
|
|
||
| This blog is about the paper “Trace-based Just-in-Time Type Specialization for Dynamic Languages” by Gal et al. |
There was a problem hiding this comment.
Please make this a hyperlink to the paper.
| At a high level, TraceMonkey works by first monitoring for hot loops by using counters. | ||
| Once hot loops are identified, it checks for type stability throughout the loop. | ||
| If it is type stable, then it can emit corresponding code that is closer to efficiency to that of a statically-typed language. | ||
| It can also detect violations of this assumption and resolve them at runtime. |
There was a problem hiding this comment.
I don't think this is an accurate description of the technique from the paper. This description makes it sound like the unit of code generation is a loop, i.e., we find the hot loops and compile those chunks of static code by making assumptions about the types. But that's not the spirit of what's going on with tracing: the unit of code generation is a trace: we start tracing when we find a hot loop, and the tracing is what determines the code to generate. So it's not the code of the loop that we start with—it's a dynamic trace through the execution of a single iteration of the loop.
It seems important to capture this central idea if you want to summarize the key contribution of the paper. Concepts like guards and deoptimization flow from this central idea, so it will be hard to discuss further technical points without this foundation.
| For these and other reasons, TraceMonkey has long been deprecated, but it directly influenced its successors: JagerMonkey, WarpMonkey, and IonMonkey. | ||
| Each of these compilers use more method-based JIT compiling while still incorporating trace-based compilation in a hybrid approach. Similarly, JavaScript JIT compilers for other popular browsers — Chrome and Safari — also used a method-based approach. Is this to say trace-based JITs are less effective than method-based JITs? Not quite; the ideas presented in TraceMonkey still live on in several ways. In addition to the previously stated fact that the newer Firefox JITs still use tracing, the predominant JIT compilers for Python and Lua (PyPy and LuaJIT respectively) all heavily rely on tracing, with LuaJIT considered being one of the fastest JITs ever. | ||
| It may be helpful to go into more detail about the transition to focusing on method tracing. | ||
| Trace-based compiling excels when control flow is simpler, but on the web, control flow can be highly irregular for several reasons: dynamic input, user interaction, etc. |
There was a problem hiding this comment.
Trace-based compiling excels when control flow is simpler
I'm not sure I agree with this assertion, or at least I think you haven't presented enough evidence for the assertion to be convincing. There is a lot of branching but those branches are "stable," then it seems like tracing is a wonderful way to automatically eliminate a lot of it in the common case.
| > Fun fact: TraceMonkey is recognized as the first JavaScript JIT compiler, beating V8 by a couple of months. | ||
| > In general, we have seen the introduction of JavaScript JIT compilers completely revolutionize the web. | ||
| > Their introduction meant games can be run in browsers, we could have crazier animations, etc. | ||
| > It was the start of an era where the web is plagued by insane amounts of JavaScript. |
There was a problem hiding this comment.
It seems like this fact probably belongs at the very beginning of the blog post, when you're introducing TraceMonkey for the first time?
|
Hi, @ethanuppal and @tean-lai: do you plan on finishing up this blog post? I'd love to publish it if you do! |
|
Yes, I will handle these soon. |
|
Hi, y'all! Just wanted to check in about wrapping up this post—it would be great to get it merged. |
|
Looks like "soon" will have to be redefined to ~3 months now. Not sure how this slipped my mind. |
|
So just to confirm - you would like us to add content from the corresponding discussion thread? If memory serves me well, I don't think Tean or I had much thoughts beyond what we wrote on TraceMonkey specifically (although we did have many thoughts on tracing JITs, the evolution of SpiderMonkey, etc., but these weren't relevant to a post specifically about TraceMonkey). |
|
Any combination of those two things (ideas from the discussion thread, or tenuously-connected thoughts about JITs in general even if they don't have much to do with TraceMonkey specifically) would be good! |
I see, sounds good |
2 participants
We apologize again for the late due date and appreciate being allowed to submit late.
We tried to omit background and other information we considered "redundant" (e.g. background) to avoid filler; I am not even quite happy with how concise we are, but it will suffice. I include this notice in case you judge the writing to be too short, in which case we will look harder for more relevant information that is simultaneously not precise details of the paper.