Java "Virtual Machine" vs. Python "Interpreter" parlance?
In this post, "virtual machine" refers to process virtual machines, not tosystem virtual machines like Qemu or Virtualbox. A process virtual machine issimply a program which provides a general programming environment -- a programwhich can be programmed.
Java has an interpreter as well as a virtual machine, and Python has a virtualmachine as well as an interpreter. The reason "virtual machine" is a morecommon term in Java and "interpreter" is a more common term in Python has a lotto do with the major difference between the two languages: static typing(Java) vs dynamic typing (Python). In this context, "type" refers toprimitive data types -- types which suggest the in-memory storage size ofthe data. The Java virtual machine has it easy. It requires the programmer tospecify the primitive data type of each variable. This provides sufficientinformation for Java bytecode not only to be interpreted and executed by theJava virtual machine, but even to be compiled into machine instructions.The Python virtual machine is more complex in the sense that it takes on theadditional task of pausing before the execution of each operation to determinethe primitive data types for each variable or data structure involved in theoperation. Python frees the programmer from thinking in terms of primitive datatypes, and allows operations to be expressed at a higher level. The price ofthis freedom is performance. "Interpreter" is the preferred term for Pythonbecause it has to pause to inspect data types, and also because thecomparatively concise syntax of dynamically-typed languages is a good fit forinteractive interfaces. There's no technical barrier to building an interactiveJava interface, but trying to write any statically-typed code interactivelywould be tedious, so it just isn't done that way.
In the Java world, the virtual machine steals the show because it runs programswritten in a language which can actually be compiled into machine instructions,and the result is speed and resource efficiency. Java bytecode can be executedby the Java virtual machine with performance approaching that of compiledprograms, relatively speaking. This is due to the presence of primitive datatype information in the bytecode. The Java virtual machine puts Java in acategory of its own:
portable interpreted statically-typed language
The next closest thing is LLVM, but LLVM operates at a different level:
portable interpreted assembly language
The term "bytecode" is used in both Java and Python, but not all bytecode iscreated equal. bytecode is just the generic term for intermediate languagesused by compilers/interpreters. Even C compilers like gcc use an intermediatelanguage (or several) to get the job done. Java bytecode containsinformation about primitive data types, whereas Python bytecode does not. Inthis respect, the Python (and Bash,Perl,Ruby, etc.) virtual machine truly isfundamentally slower than the Java virtual machine, or rather, it simply hasmore work to do. It is useful to consider what information is contained indifferent bytecode formats:
- llvm: cpu registers
- Java: primitive data types
- Python: user-defined types
To draw a real-world analogy: LLVM works with atoms, the Java virtual machineworks with molecules, and The Python virtual machine works with materials.Since everything must eventually decompose into subatomic particles (realmachine operations), the Python virtual machine has the most complex task.
Intepreters/compilers of statically-typed languages just don't have the samebaggage that interpreters/compilers of dynamically-typed languages have.Programmers of statically-typed languages have to take up the slack, for whichthe payoff is performance. However, just as all nondeterministic functions aresecretly deterministic, so are all dynamically-typed languages secretlystatically-typed. Performance differences between the two language familiesshould therefore level out around the time Python changes its name to HAL 9000.
The virtual machines of dynamic languages like Python implement some idealizedlogical machine, and don't necessarily correspond very closely to any realphysical hardware. The Java virtual machine, in contrast, is more similar infunctionality to a classical C compiler, except that instead of emittingmachine instructions, it executes built-in routines. In Python, an integer isa Python object with a bunch of attributes and methods attached to it. InJava, an int is a designated number of bits, usually 32. It's not really afair comparison. Python integers should really be compared to the JavaInteger class. Java's "int" primitive data type can't be compared to anything inthe Python language, because the Python language simply lacks this layer ofprimitives, and so does Python bytecode.
Because Java variables are explicitly typed, one can reasonably expectsomething like Jython performance to be in the same ballpark ascPython. On the other hand, a Java virtual machine implemented in Pythonis almost guaranteed to be slower than mud. And don't expect Ruby, Perl, etc.,to fare any better. They weren't designed to do that. They were designed for"scripting", which is what programming in a dynamic language is called.
Every operation that takes place in a virtual machine eventually has to hit real hardware. Virtual machines contain pre-compiled routines which are general enough to to execute any combination of logical operations. A virtual machine may not be emitting new machine instructions, but it certainly is executing its own routines over and over in arbirtrarily complex sequences. The Java virtual machine, the Python virtual machine, and all the other general-purpose virtual machines out there are equal in the sense that they can be coaxed into performing any logic you can dream up, but they are different in terms of what tasks they take on, and what tasks they leave to the programmer.
Psyco for Python is not a full Python virtual machine, but a just-in-timecompiler that hijacks the regular Python virtual machine at points it thinks itcan compile a few lines of code -- mainly loops where it thinks the primitivetype of some variable will remain constant even if the value is changing witheach iteration. In that case, it can forego some of the incessent typedetermination of the regular virtual machine. You have to be a little careful,though, lest you pull the type out from under Psyco's feet. Pysco, however,usually knows to just fall back to the regular virtual machine if it isn'tcompletely confident the type won't change.
The moral of the story is that primitive data type information is reallyhelpful to a compiler/virtual machine.
Finally, to put it all in perspective consider this: a Python program executedby a Python interpreter/virtual machine implemented in Java running on a Javainterpreter/virtual machine implemented in LLVM running in a qemu virtualmachine running on an iPhone.
A virtual machine is a virtual computing environment with a specific set of atomic well defined instructions that are supported independent of any specific language and it is generally thought of as a sandbox unto itself. The VM is analogous to an instruction set of a specific CPU and tends to work at a more fundamental level with very basic building blocks of such instructions (or byte codes) that are independent of the next. An instruction executes deterministically based only on the current state of the virtual machine and does not depend on information elsewhere in the instruction stream at that point in time.
An interpreter on the other hand is more sophisticated in that it is tailored to parse a stream of some syntax that is of a specific language and of a specific grammer that must be decoded in the context of the surrounding tokens. You can't look at each byte or even each line in isolation and know exactly what to do next. The tokens in the language can't be taken in isolation like they can relative to the instructions (byte codes) of a VM.
A Java compiler converts Java language into a byte-code stream no different than a C compiler converts C Language programs into assembly code. An interpreter on the other hand doesn't really convert the program into any well defined intermediate form, it just takes the program actions as a matter of the process of interpreting the source.
Another test of the difference between a VM and an interpreter is whether you think of it as being language independent. What we know as the Java VM is not really Java specific. You could make a compiler from other languages that result in byte codes that can be run on the JVM. On the other hand, I don't think we would really think of "compiling" some other language other than Python into Python for interpretation by the Python interpreter.
Because of the sophistication of the interpretation process, this can be a relatively slow process....specifically parsing and identifying the language tokens, etc. and understanding the context of the source to be able to undertake the execution process within the interpreter. To help accelerate such interpreted languages, this is where we can define intermediate forms of pre-parsed, pre-tokenized source code that is more readily directly interpreted. This sort of binary form is still interpreted at execution time, it is just starting from a much less human readable form to improve performance. However, the logic executing that form is not a virtual machine, because those codes still can't be taken in isolation - the context of the surrounding tokens still matter, they are just now in a different more computer efficient form.
Probably one reason for the different terminology is that one normally thinks of feeding the python interpreter raw human-readable source code and not worrying about bytecode and all that.
In Java, you have to explicitly compile to bytecode and then run just the bytecode, not source code on the VM.
Even though Python uses a virtual machine under the covers, from a user's perspective, one can ignore this detail most of the time.