abstract machine concept of jvm

Question

I am trying to understand the real advantage of implementing java as an abstract or virtual machine or in other words the advantage of compiling a language into a language for an abstract machine. As far as platform independence is concerned I was thinking of the following two alternative implementations:

• just having an interpreter which translates java directly into machine code of the machine it is running on and having multiple implementations of such an interpreter for different type s of machine.

• the first option is not efficient in space so how about compiling the source code to an intermediate language which is not a language for an abstract machine but just some language which can be interpreted to machine code and then having multiple implementations of such interpreters.

If performance is not considered how does having an abstract machine compare with these options. In other words what if java byte code is not a language for a virtual machine but just some intermediate language.What features and benefits would be lost (except for performance)?

Answer 1

Bytecode is just an intermediate language.

Or the other way round: The implementation of an intermediate language is a virtual machine.

Answer 2

If Java was translated directly to machine code as it is executed you would lose the type safety features that the compiler provides. The fact that the compiler reports no errors guarantees that certain types of errors cannot occur in runtime; if you remove the compiler phase you would see these errors in runtime.

On the other hand, Java bytecode is an intermediate language, even if it's a little higher level than others. JVMs execute it partly by interpreting and partly by compiling to machine code.

Answer 3

What you describe is essentially what Java and the JVM do currently. Java is compiled to something called bytecode, which is an intermediate language (that happens to look an awful lot like assembly for a stack based machine). The JVM then interprets this code, translating parts of it to machine code on the fly in a process called Just In Time (JIT) compilation. The JVM does other things (like manage concurrency and memory structure/management) which aid in portability.

Answer 4

All variants are actually in use in practice, it is all about choosing appropriate compromises.

for Java - convenient for many platform distribution, slower startup times:

• Java source compiled to bytecode
• bytecode interpreted and/or
• bytecode JIT compiled to machine code

for JavaScript - the most convenient for distribution / a lot of work to be done to make it fast):

• JavaScript source parsed+interpreted or JIT compiled to machine code

for .NET - AOT has all advantages of VM language while keeping startup time fast, but mostly locked to one target system type:

• C#/F#/VB/... compiled to IL (intermediate language / another bytecode)
• .NET IL code interpreted and/or
• .NET IL JIT compiled to machine code or
• .NET IL AOT compiled (ahead of time) (to x86 mostly) and distributed compiled

this is just what is mostly being used, but you can compile javascript to bytecode, precompile java to machine code, you can even compile Java to javascript like GWT does, etc. (only there is a lot to do to make it usable)