7

I know what the JIT compiler is but how about why is it called that, it obviously catches exceptions Just in Time, but how and why should it be called this?

Sorry if this sounds a bit vague.

  • 1
    I'd guess the actual "why" is "because JIT was a popular management buzz-phrase when Java started doing it, and they were trying to capitalize on that popularity." – Jerry Coffin Jul 10 '12 at 05:19

5 Answers5

23

The Just-In-Time compiler doesn't have anything to do with exceptions. It refers to when code is compiled. Some languages, like Java, are translated from the language that you program in with your favorite editor into byte code. At runtime, some byte code might be further compiled into native code just prior to execution (hence the name, just-in-time). This is in contrast to some languages, like C, that are compiled into native machine code at the time when you invoke the compiler.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • This term seems to have been coined in relation to Java byte code. What is peoples opinion on "scripting languages", those that are compiled at execution time? JIT, or something else? – Paul Jul 09 '12 at 16:53
  • @Paul: Some scripting languages have JIT in addition to (or instead of) interpretation. – DeadMG Jul 09 '12 at 17:20
  • 3
    @Paul The JITing concept actually dates back to 1960 LISP. The JVM's JITer was derived from Sun's research on JITing small talk. Java's JITer is only notable for being the first one to go mainstream. – Dan Is Fiddling By Firelight Jul 09 '12 at 19:41
  • 1
    I was under the impression that part of the idea behind was that when that JIT compilation occurred, it could compile using processor-specific optimizations that wouldn't otherwise be possible since people have different models/steppings/etc. of microprocessor. – Mark Allen Jul 09 '12 at 21:14
  • 5
    That's certainly possible, given adequate knowledge by the runtime of the machine it's running on. But, the primary advantage is that the intermediate code you write that is JITed by the runtime doesn't have to know what processor, or even what OS, it is being run on, so the same Java code could run on any computer from a PowerPC Mac with OS9 to a newer Intel OSX Mac to a Win7/Vista/XP/2000 machine to a quad-Xeon blade server running a LAMP/LAMJ stack. – KeithS Jul 09 '12 at 22:46
  • @MarkAllen: No, that's not the interesting bit. You don't need to compile the program every single time over and over again while it is running for that. It would be enough to compile it once, when it is being installed or only recompile it when you install a new processor or a new compiler. (This is what LLVM was originally intended for, BTW.) Compiling the program dynamically while it is running gives you access to information that is simply not available statically. For example, optimizing virtual method calls into static method calls is impossible to do with an ahead-of-time compiler, … – Jörg W Mittag Jul 10 '12 at 11:07
  • … because determining whether a method could be overridden or not is essentially equivalent to solving the Halting Problem. But for a JIT compiler, it's trivial: if you want to know whether a method has been overridden or not, just look. The program is already running, all the methods are there. And even if, like in Java, the system allows you to load new code after the program has started running, and it turns out that a method that wasn't previously overridden now gets overridden by code that is loaded later, no problem: just throw away the compiled code, and recompile with new information. – Jörg W Mittag Jul 10 '12 at 11:10
5

The name comes from the "just in time" manufacturing methodology, wherein parts are delivered "just in time" to be installed. In manufacturing, it costs a lot of money to keep parts and supplies in inventory, and producing and delivering them as they're needed makes a process cheaper/more efficient.

The Java JIT compiler works in a way that's analogous to JIT manufacturing: instead of compiling code beforehand and keeping it around, it compiles code as its needed. This gives you short development cycles and immediate feedback of an interpreted language and the speed of a compiled language.

Caleb
  • 38,959
  • 8
  • 94
  • 152
  • 1
    you don't really get the feedback of an interpreted language. You still need to compile .java to .class, and the only way to do that 100% reliably is to compile them all. Then you need to restart the JVM to load the modified .class files. – kevin cline Jul 09 '12 at 18:50
  • @kevincline: It is possible to get more real-time feedback, even with Java; most Java debuggers allow you to execute small bits of code while at a breakpoint. But other languages do this much better: F# for example has an interactive REPL implemented with a JIT compiler. – Daniel Pryden Nov 19 '12 at 20:20
  • @Daniel, great but what happens when I find the problem and want to fix it? Or when I just want to add the code to pass the next test? Those JVM restarts really take a toll. – kevin cline Nov 19 '12 at 22:23
  • @kevincline: I agree, in the Java world it isn't very interactive. But that's a problem with the Java implementation, not with the approach of JIT compiling in general. For example, Visual Studio allows you to edit C# code while it's running and it re-JITs on the fly, so it can be done. – Daniel Pryden Nov 20 '12 at 02:06
3

In .Net, say when a C# program is compiled, it is compiled into what is called "Microsoft intermediate language" (MSIL) Code, this code is machine independent. The MSIL Code is not directly executable as is. It must be converted (and optimized) to code that can be executed by the target OS (and CPU). That conversion occurs when you request a .Net program to run and is performed by the Just In Time (JIT) compiler, the JIT produces executable that is specific to OS (and CPU) you are running the application on. So the name Just In Time, indicates that the compilation from MSIL to native OS code only occurs when you request the code to execute. For more information see Compiling MSIL to Native Code.

NoChance
  • 12,412
  • 1
  • 22
  • 39
1

Code is compiled when called. It is compiled just in time, or just before it is called if you prefer.

This apply to methods. If a method is never called, it is never compiled.

1

It doesn't have anything to do with exceptions.

The name reflects the fact that the software is not compiled into machine code until it is about to be executed. This allows you deploy an application to multiple computers and have machine-specific optimizations applied at runtime.

sourcenouveau
  • 6,460
  • 4
  • 29
  • 44