Why is bytecode JIT compiled at execution time and not at installation time?

7
votes

Compiling a program to bytecode instead of native code enables a certain level of portability, so long a fitting Virtual Machine exists.

But I'm kinda wondering, why delay the compilation? Why not simply compile the byte code when installing an application?

And if that is done, why not adopt it to languages that directly compile to native code? Compile them to an intermediate format, distribute a "JIT" compiler with the installer and compile it on the target machine.

The only thing I can think of is runtime optimization. That's about the only major thing that can't be done at installation time. Thoughts?

3
compilationdistributionjitbytecode
if you update the VM will you have to recompile all your programs? or if you change any dependencies will you have to resolve which apps are affected and recompile them? – jqa
Also, you seem to massively underestimate. Being able to utilize all the state-of-the-art tricks of the CPU without compiling 20 executables is nice, but all this doesn't help help performance much if you have unresolved dynamicness in the program. The runtime optimizations of many JITs work to eliminate that dynamicness when all the data needed to do so is there - at runtime. – user395760
@james: Those are indeed valid points. But they are more or less the same for languages which compile directly to native code. Maybe I'm just looking for a way to have easier cross-plattform distribution for native apps. – Xeo

3 Answers

1
votes

Often it is precompiled. Consider, for example, precompiling .NET code with NGEN.

One reason for not precompiling everything would be extensibility. Consider those languages which allow use of reflection to load additional code at runtime.

1
votes

Some JIT Compilers (Java HotSpot, for example) use type feedback based inlining. They track which types are actually used in the program, and inline function calls based on the assumption that what they saw earlier is what they will see later. In order for this to work, they need to run the program through a number of iterations of its "hot loop" in order to know what types are used.

This optimization is totally unavailable at install time.

0
votes

The bytecode has been compiled just as well as the C++ code has been compiled.

Also the JIT compiler, i.e. .NET and the Java runtimes are massive and dynamic; And you can't foresee in a program which parts the apps use so you need the entire runtime.

Also one has to realize that a language targeted to a virtual machine has very different design goals than a language targeted to bare metal.

Take C++ vs. Java.

  • C++ wouldn't work on a VM, In particular a lot of the C++ language design is geared towards RAII.
  • Java wouldn't work on bare metal for so many reasons. primitive types for one.

EDIT: As delnan points out correctly; JIT and similar technologies, though hugely benificial to bytecode performance, would likely not be available at install time. Also compiling for a VM is very different from compiling to native code.