Take the 2-minute tour ×

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?

share|improve this question
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? –  james Jun 18 '11 at 23:39
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. –  delnan Jun 18 '11 at 23:43
@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 Jun 18 '11 at 23:44

3 Answers 3

up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
Compiling pretty much means "translating" (from one computer language to another). There's nothing weird about compiling the output of a compiler. –  delnan Jun 18 '11 at 23:28
@delnan No there is nothing weird about it sure, but fine, lets disagree on the complexity of compiling source to bytecode, to compiling bytecode to native. –  Captain Giraffe Jun 18 '11 at 23:33
It may be simpler (doesn't need to, though - the JIT parts of PyPy is a tremedous piece of genius, with multiple optimizations passes, its own bytecode format, etc. compared to its bytecode compiler, which doesn't need to check types and has a very high-level target format, for starters) but that doesn't make it less of a compiler. –  delnan Jun 18 '11 at 23:39
@delnan Exactly, the JIT genius is nothing like compilation to me. We are getting to semantics that I don't think the OP intended here. –  Captain Giraffe Jun 18 '11 at 23:43
A JIT compiler is a compiler, as evident by the name. The way it gathers its input is different, and its output is executed right away, the languages it operates on are relatively low-level compared to the languages we use, but that's just details. All the internals, the things which make 99% of the JIT code, are the usual compiler stuff - analyse and optimize some internal representation, then generate code. Heck, many optimizations of "traditional" compilers are borrowed 1:1 by JIT compilers! –  delnan Jun 18 '11 at 23:47

Your Answer


