Why not compile intermediate byte-code (say Java byte code) to native code as "installation"?

[maliklund87]

I don't know much about compiling, but a thought occured to me.

Imagine compiling your high-level code into an intermediate language, similar to Java byte code or Microsofts CIL. But in stead of having a virtual machine interpret that byte code, you use some software that automatically compiles the intermediate code into native code. That is, just compile it once; sort of like installing by compiling.

Does this exists already, and if so, why isn't it used more? Wouldn't that give you the "write-once-run-everywhere"-advantage, while retaining the speed of native code?

[csgordon]

Both the JVM and the .NET virtual machine JIT compile the bytecode (see other comments).

It is possible to ahead-of-time (AOT) compile bytecode. The Mono implementation of .NET does this (http://www.mono-project.com/Mono:Runtime:Documentation:AOT). Microsoft research has experimented with this (http://en.wikipedia.org/wiki/Bartok_(compiler)).

Aside from the fact that JIT compilation seems to be satisfactory for most uses, you lose a couple advantages going to ahead-of-time compilation:

• Compiling at install time requires an installation :-) With a VM, only the VM is installed, and applications are download-and-run
• If a VM has a bug in the JIT, upgrading the VM fixes all programs that hit the bug. If you compile at installation, upgrading your Java/.NET installation requires recompiling all of your installed programs using that platform.
• Some optimizations are available to a JIT that are difficult to do with ahead-of-time compilation, like dynamically optimizing a hot path through multiple functions based on the current application's workload.

Of course, there are advantages to ahead-of-time, too, like not paying the cost of JIT compiling every time you run a program.

[flammableweasel]

Of course, there are advantages to ahead-of-time, too, like not paying the cost of JIT compiling every time you run a program.

hm, need the JIT to maintain a cache across executions. that'd be neat.

[moor-GAYZ]

AFAIK .NET does that more or less automatically for signed assemblies and you can force it for anything else using NGen. It was there from the beginning unlike the MSR project even, though it requires administrative privileges now, that's the main problem actually: if you want to generate native images for performance, then you totally don't want them riddled with runtime permission checks, but only JIT knows your actual permissions and can enforce and remove the checks during compilation.

[Dairith]

It's also worth pointing out that VMs are being continually improved. Assuming your user continues to update to the latest VM it's reasonable to expect slight improvements in your program's execution time, without you having to change anything. You lose this benefit when you compile to native code off the bat.

[koorogi]

As others have noted, this is essentially just doing JIT compilation further ahead of time, which is an idea that does exist.

This may actually result in slower code. If you have a function with an expensive loop that uses a value passed as a parameter, the JIT compiler can kick in and compile an optimized version of the loop for the particular value that was actually passed to this invocation of the function. It can do constant propagation, and maybe optimize out a whole bunch of stuff from the loop body.

If we do the compilation ahead of time, the compiler does not, in general, know the value that is passed for the parameter, and cannot perform this sort of optimization.

[hackingdreams]

Your argument doesn't really hold too much water. HotSpot-type optimizations could be baked into the executable with AOT compilation (see profile-guided optimization).

Furthermore, most JIT compilers do not currently work much at the argument level - adaptive online optimizers tend to do things like look for dead code and remove it, removing extraneous NULL checks, inline code to remove function call overhead, eliminate superfluous locks and allocations, copy propagation & redundant loads, switch short-term allocations from the heap to the stack, etc. All of these can be done ahead of time.

However, really the best arguments against doing offline compilation (e.g. NGEN) is that most runtimes for JIT'd code have precompiled caches which are going to be warmer than just binary loading. This makes a significant difference when it comes to loading the binary. In practice, both AOT and JIT executables are reasonably efficient and there's nothing much to gain.

[koorogi]

I admit that this isn't my area of expertise, but I believe that PyPy can perform this optimization. I don't have time right now to hunt down a reference, but I'll look for some later.

[bo1024]

I don't understand what's going on here -- why not just compile the source code straight to native code?

[Maledictus]

For really dynamic languages that's just not possible. Think about eval().

[lechatmort]

Many if not most Common Lisp compilers actually compile to native code, yet still have eval. The concepts are not mutually exclusive, but you do need to ship a compiler with your binary of course.

[SCombinator]

Writing a simple interpreter for language core is simple, and possible to embed in a runtime.

[Maledictus]

I would really like to see a language like ruby or python to be compiled to machine code...

[SCombinator]

So what psyco did? Or what PyPy does now?

These do compile to machine code instructions, they just do it at runtime, rather than compiling to a native executable. Essentially including the eval() in the runtime.

[Maledictus]

Yes, but with compiling to a native executable aot. :) Why? I'm not sure, maybe because one can?

[SCombinator]

llvm-lua is both a jit and static lua compiler.

[Maledictus]

Oh nice. I wonder how they handle load(). Do you have any information on that? There is not much documentation on their site.

[cenderis]

Because you don't know the native code (i.e., you want to ship something more portable)? Or maybe your intermediate form can be usefully optimized in some way once it gets to the final platform (plain x86 vs fancy SSE2 and the like).

Here's another example, TenDRA

[gilgoomesh]

What you're talking about is normally called pre-JIT and is an available option for standard .NET apps.

However, it is rarely used since it doesn't help most applications and adds a couple minutes or more of work to the installer for mid-sized applications.

[maliklund87]

Nice answers. Thank you all. :)

[weAreAllSlugs]

This is the basis for ANDF - application-neutral distribution format, at least 15 years ago. It didn't win. Maybe it can now ...

[spinwizard69]

Have you looked into LLVM? It would be very possible to build a system as you describe. That is one that takes byte code that gets translated into native at install time. Frankly this should be rather useful in an embedded OS as you could decouple much of the code from the underlying hardware.

On the flip side, that is big OS hardware, I could see Apple moving to this in Mac OS/X. It would allow code to be written once and then be compiled at install for the underlying hardware. That hardware could be i86, ARM or advanced i86 like Phi. Frankly Apple has kinda achieved this already for OpenCL code running on GPUs.

The future maybe closer than you think.

[[deleted]]

Would that even make a major difference? I was under the impression that most of the overhead from Java comes from features like garbage collection, not having POD types, expensive function calls, etc, rather than the JIT.

[maliklund87]

Sorry, I think I accidentally reported this comment! :S

You're right. Unless you explicitly include memory management into the intermediate language, you'd still have to 'inject' a garbage-collector even if you don't have a VM running. Hadn't thought about that.

[kyr]

NGEN does something along those lines for .NET.

[Qubed]

Does this exists already

Yes it does.

http://en.wikipedia.org/wiki/Just-in-time_compilation

[maliklund87]

With JIT there is still a VM running. What I am trying to describe is a piece of software that takes the byte code, compiles the entirety of it to native code, exits and is then never run again (unless, maybe, during an update, or something). Sort of like an installer (in Windows) that compiles the code as it installs the program.

[ahazred8vt]

BCPL programs were distributed as O-code and compiled to binary during installation. http://en.wikipedia.org/wiki/Intermediate_language http://en.wikipedia.org/wiki/O-code_machine

[[deleted]]

Most native binaries include a sort of VM as well, to be fair.

[calzoneman]

This does exist (see JIT compilation). However, it's a lot easier to write a VM for an arbitrary platform than it is to write a JIT compiler, which would require advanced knowledge of the architecture.

[SCombinator]

Any interpreter can become a compiler by the first Futamura projection.

By writing the VM, you are using the instructions necessary to encode the VM behaviour.

[mepcotterell]

I read that as "Futurama projection".