Hacker News Reader

Comment by exDM69 | Hacker News Reader

It's a bit more complex than that. First a bit of clarification on terminology: it seems like everything that's compiling code at runtime is called JIT, but I don't like that definition. For a language implementation to qualify as JIT, it has to have an interpreter, a compiler and passing control between compiled and interpreted code.

This is where the complexity is, managing when to JIT compile a function and how to pass control back to the interpreted code. There are so many ways to do this, from compiling individual functions to doing a tracing JIT like luajit is.

So, yes, the compiler part of a JIT is "just" a compiler that outputs code to memory but the complexity is doing it just-in-time. Start executing code in an interpreter, find a hot path, then compile that and make the compiler emit instructions that return the control back to the interpreter when executing the hot path is done.

View on HN

> For a language implementation to qualify as JIT, it has to have an interpreter, a compiler and passing control between compiled and interpreted code.

So you wouldn't consider the .NET framework a JIT? It never interprets any code, just compiles things as they are used.

Or V8? V8 doesn't have an interpreter (it is now getting one), but is perhaps the major example of a JIT most people would know.

Saying you need an interpreter is clearly a silly definition of a JIT.

V8 is definitely a JIT. It might not have an interpreter in the classical meaning of the word, but it does incrementally compile more as type information becomes available.

It compiles some code, executes it and control returns back to either interpreted code or the framework that decides what to compile next. It's a JIT, because it can't be done ahead of time.

Just doing the final stage of code generation at runtime/startup (like, say, PNaCL does) would not qualify. You could as well generate code for all target architectures ahead of time, but it might be more practical to leave that to the client.

Feel free to disagree with my definition, but I like to draw a distinction between just compiling code at runtime and a JIT, that compiles/optimizes code as it becomes possible.

> I like to draw a distinction between just compiling code at runtime and [something else] that compiles/optimizes code as it becomes possible

I agree with that, but I call the first thing a JIT, and the second thing a dynamic compiler. There's a PhD someone wrote about the difference but I can't find it now.

I guess we can agree that the term is somewhat ill defined but the distinction exists :)

First of all: it's a bit of an ill-defined term and someone else might have a different definition that contradicts mine.

I'm not too familiar with .NET but based on your description, no I would not qualify that as a JIT according to the definition I gave above.

If you could as well do it ahead of time, I would not call it a JIT.

Is the reason for .NET's late compilation to generate code for the target CPU architecture? Or does it do some optimization based on runtime information (this would qualify as JIT)?

It doesn't necessarily have to be a (bytecode) interpreter to call it a JIT, but it does have to compile code at runtime and have the control return back to the framework for compiling more code as needed.

I don't believe it does any runtime optimization, but it does compile code on-demand. Compiled code returns control to the compiler, but not interpreted code since there is none. IIRC this is done in a similar manner to garbage collection pauses (via interception of bad memory accesses).

If the control returns from the compiled code, I'd call it a JIT.

Do you know why it's doing incremental compilation? Is there something that can't be done ahead of time? E.g. inlining dynamic ("virtual function") calls and then applying optimization?

Mostly to avoid compiling much code that doesn't actually get executed. For the most part you can do everything ahead of time via static analysis (Xamarin's iOS toolchain does this). The only exception is access of code via reflection, which is harder to statically analyze and will also invoke the JIT.

Wait a second, I thought .NET is interpreted? I mean take C#. Isn't it compiled to IL and then run on CLR VM? And has JIT to speed it up?

EDIT: spelling

The JIT always runs - there's no interpreter, so if your need to run a method the first thing the VM does is to JIT compile it.

This has some disadvantages - you have to wait for the JIT to run and can't keep running in the interpreter while it compiles, and some advantages - it's simpler.

No, when .NET came out computers had gotten fast enough that the JIT pauses around startup were manageable, so they didn't use interpretation as a stopgap like the JVM did (which was created much earlier).

Reply on news.ycombinator.com