(First of all, I should make clear that compilers and virtual machines (aka) are a completely unknown field for me)

As I understand it, every time a Java/C#/... application is run, a VM is invoked and translates intermediate code (bytecode, CIL, etc) to machine instructions.

But why can't this operation done only once - at install time?

  • 1
    What is install time? – Peter Taylor Oct 31 '11 at 8:41
  • 3
    Not sure if it's a standard term, but I meant: when the user installs the program -runs it for the first time-, as opposed to compile a program in the developer's machine (who can't know the platform a given user will use - and you don't want to distribute one installer per platform). – vemv Oct 31 '11 at 10:29
  • @vemv compiling at runtime allows the VM to specialize the machine instructions for your particular hardware – Lucina Oct 13 '13 at 8:01

In the case of Java, the JVM can do optimizations that cross library boundaries. For example you could inline a method from a library into your own client code. This type of optimization could not be done at compile time, because the library may change before execution. It is entirely possible that your libfoo-1.0 is replaced by libfoo-1.1 without a recompile. If that happens, cross-library inlines done at compile time would become totally invalid.

By doing the optimization solely at runtime, there is no worry that the library changing under you will invalidate optimizations.

  • 1
    An inline could be instead of generating machine code to call a "Y.setX(x)" (where Y is from a third part library) which then runs "this.x = x" then just generate machine code for "Y.x = x". – user1249 Oct 31 '11 at 8:54
  • In summary, runtime has information that the compile time doesn't. – jozefg Nov 6 '13 at 15:13

Because this prevents them from using many features. For example, how can the JIT generate new generic instantiations from DLLs loaded at run-time? Those DLLs don't exist at install-time.

  • 1
    Cheers for the answer. I think I get the instantation issue - can't be 100% sure though because your reply is a bit too succint. Also listing other unavailable features would make your point stronger. – vemv Oct 30 '11 at 13:43
  • 3
    Or in general: a JIT can do optimizations based on input; DLLs loaded at run-time are one type of input. – amara Oct 30 '11 at 13:50
  • 1
    Obviously, those DLL's are installed as well, and each DLL could be compiled at its install time. You lose cross-module optimizations, but those are a bit theoretical anyway. – MSalters Oct 31 '11 at 12:14
  • @MSalters: Not every DLL has an "install" time. – DeadMG Oct 31 '11 at 21:46
  • @DeadMG: We're takling about hypothetical systems anyway; such a system may easily require installation. (It would be a security benefit, additionally, if the introduction of executable code would be explicitly managed). – MSalters Nov 1 '11 at 8:57

It can and often is, at least with .NET applications. See Native Image Generator

a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly...

  • Note that this is also similar to the Android Runtime (ART) built by Google to improve performance of Android Apps – neelsg Nov 11 '14 at 7:24

To rephrase the question in accordance with the clarification:

Why can't the bytecode be compiled down to native code the first time the program is run?

I see the following problems:

  • Where would the results be stored? You can't assume that the file containing the bytecode is writable; you don't want to bloat a developer's machine by dumping a new .exe to permanent storage each time he runs a test; and if you store the file in temporary storage then it will be lost the next time you reboot, so you haven't gained much.

  • You're trading away a slightly slow startup every time for a very slow startup the first time. Not going to leave a great impression with the client.

  • You're going to have significant trouble with dynamic classloading.

  • 2
    The first point is trivial. Caches are quite well understood. When the underlying executable bytecode is removed, you can delete the associated cache entry, and also if it's not run for too long. As for the second point, you can do the compilation of unused methods in a background thread. This should not hinder startup time, where you compile called methods in the foreground. – MSalters Oct 31 '11 at 12:18
  • As far as I understand, the question is not about compiling at the first run, but compiling at installation. – Nemanja Trifunovic Oct 31 '11 at 13:00
  • @NemanjaTrifunovic, read the comments on the question. – Peter Taylor Oct 31 '11 at 13:13
  • 1
    I'm afraid I didn't explain myself well, sorry. I meant the first time an application is ever run, then no further compilations would be needed anymore. Just like when you have to compile a C program before using it on Linux. – vemv Oct 31 '11 at 15:45
  • 1
    I think it pretty much counts as an install - those compilations/build processes are already scripted for you. – vemv Nov 2 '11 at 3:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.