Java "Compilation" vs. MSIL "Compilation"

[SONYFX]

Is this correct?

Java:

Java code is compiled into Byte Code which is stored in a ".class" file until runtime. At runtime, the Java Virtual Machine interprets the Byte Code and then executes machine code accordingly. At no point is the Java Byte Code compiled directly into machine code.

.NET:

Code written in any .NET language (C#, VB.NET, C++.NET, etc.) is compiled into MSIL, which is stored in an assembly file. At runtime, the Common Language Runtime compiles that MSIL directly into machine code, which is then executed. Depending on the compilation settings, the JIT compilation results (MSIL -> machine code) may be cached for future use. It is also possible to use the NGen.exe tool to manually compile MSIL directly into machine code, and distribute an application like that.

 

[kamper]

That java one isn't entirely correct. It is possible that the jvm will simply interpret the bytecode and go from there but that's extremely slow. That will generally only happen for small jvms (for embedded devices) or possibly for code that will only run once. Any code that repeats multiple times needs to be optimized and will be compiled into native machine code and reused for a while. Generally it would only be thrown away if a class is unloaded at runtime, if the jvm exits or if the code turns out to be more important than the jvm thought and it needs to be optimized more agressively.

If your definition of java is just the sun jvm that you install on your desktop, then the vast majority of the bytecode will be compiled into machine code every time you run a new jvm. I don't know if sun's jvm even has an interpreter.

I couldn't speak for .net myself.

 

[SONYFX]

bump

 

[MrChad]

For the .NET side of things ...

http://msdn2.microsoft.com/en-us/library/k5532s8a.aspx

 

[itachi]

if by sun's jvm not having an interpreter you mean that it doesn't support static native compilation, then no.. sun does not have that. otherwise, java bytecode can't be executed without an interpreter (unless the cpu is capable of undertanding the opcodes).

java is compiled into bytecode. at runtime, the jvm runs an interpreter to begin execution.. while the interpreter runs, the jvm profiles the code. using the analysis data, it determines which methods with a large set of instructions are being invoked most frequently, and feeds that information to the jit compiler.. which stores the resultant code in memory. this is the basis for the hotspot jvm.
the profiler runs constantly while the program is running.. using the data the jvm, as kamper said, can perform more aggressive optimizations or deoptimizations if necessary. it can also determine if a compiled method is being used less, and subsequently discard the compiled code and revert to using the bytecode.

 

[kamper]

What would be the point of deoptimization or throwing compiled code out altogether? Just memory savings?

Would the jit ever inline a method that later gets over-ridden and has to be recompiled to allow for the new implementation?

 

[itachi]

Originally posted by: kamper
What would be the point of deoptimization or throwing compiled code out altogether? Just memory savings?

not simply just to reduce the memory footprint, but also to reduce the amount of page faults caused by not having enough memory. if an object allocation is requested and there's not enough memory, the gc may have to go through multiple levels to free up memory, which usually involves searching and sometimes involves heap resizing.

Would the jit ever inline a method that later gets over-ridden and has to be recompiled to allow for the new implementation?

depends on how the vendor implemented the heuristics and weighed the factors. ibm's jalapeno (jikes rvm) as an optimizing compiler will optimize based on the expected execution time of a method without recompilation, the expected execution time of a method after being optimized at a lower level, and the cost of having to recompile at the lower level. based off those factors, it decides whether or not to optimize more heavily.