(I reworded my question to make it more specific).

Consider a programming language, that it's programs may only be run inside a specific program that serves as an interpreter.

The interpreter scans each line of the source code and executes it as it is.

Would the interpreter be considered a virtual machine?

Conceptually, a VM is a program that other programs use as a platform to run inside of. Thus this interpreter suits the definition. But this interpreter only interprets plain-text source code into executions (and not bytecode).


It depends. "executing" isn't really the defining part of a virtual machine.

To qualify as a virtual machine, an interpreter would have to offer:

  • a memory model (ways for a program to acquire, use and release memory - is there garbage collection?)
  • APIs for IO (ways for programs to access files, networks, etc.)
  • optionally, a concurrency model (ways for programs to execute in parallel and coordinate)

And all of these would have to be well-defined and independent of the underlying OS and hardware. An interpreter that does all of this would have a good claim of being a VM.

| improve this answer | |
  • This interprenter is a very simple one, and is a Java program that runs on the JVM. As to memory, basically when the programmer declares a variable, the inner implementation of the interprenter to deal with this is to use Java Collections to store and access data that the programmer consideres as 'variables'. Basically, the interprenter uses high-level Java operations to implement everything. Just like the first JVM used high-level C operations to implement things (although ofcourse far, far more complex). – NPElover Mar 9 '14 at 12:08
  • So as I said, low-level memory and stuff like that is taken care of by the JVM, which the interprenter runs on. Technically, the interprenter uses functionality of the JVM. It doesn't take care of the low-level things by itself, the JVM does this for the interprenter. Would the interprenter conceptually be considered a VM? (Even though ofcourse all of the very low level stuff happens at the JVM level. For example - At high level: Programmer declares a variable. At a lower level: Interprenter saves data in a Java List. At lowest level: JVM takes care of garbage collection and low level stuff. – NPElover Mar 9 '14 at 12:13
  • @NPElover: in that case, I'd say that they interpreter by itself would not be considered a VM - it's an interpreter running on the JVM. You might have a case for calling it a VM if you ad all the stuff I mentioned exactly specified independent of the implementation and the JVM, so that it would be possible to implement your interpreter using, for example, C++ and still have programs work exactly the same. – Michael Borgwardt Mar 9 '14 at 17:12
  • Does that mean that it's impossible to create a VM using Java? All Java operations are dependent of the JVM (executing System.out.println("hi") tells the JVM to do something), and you're saying that for something to be considered a VM, it must be independent of any other VM (if I understand correctly). – NPElover Mar 9 '14 at 17:54
  • 2
    @NPElover: Exactly! – Michael Borgwardt Mar 9 '14 at 20:49

I think you're confusing a sandbox with virtual machine. A sandbox is a safe container for a single application, where as a virtual machine is a safe container for many applications. VMs often don't restrict what those apps can be, but a sandbox can be for a specific type of app.

The difference between a sandbox and an interpreter is; An interpreter can be interrupted without killing the application, where as a sandbox can only be interrupted by killing the application.

| improve this answer | |

Any interpreter could be considered a virtual machine. It entirely depends on the definition of virtual machine that you adopt.

Conceptually, a VM is a program that other programs use as a platform to run inside of. Thus this interpreter suits the definition.

Yes ...

But this interpreter only interprets plain-text source code into executions (and not bytecode).

Well your definition of virtual machine does not say anything about the nature of the "platform". So those issues are not relevant.

There is also the issue that you haven't defined "program". Depending on how you define it, your example may not be an example of VM because the interpreter is not a different program to the virtual machine. (On the other hand, that might just be a flaw in your definition of a "virtual machine".)

I would point out that there is one difference between your interpreter and (say) a Java + JVM instance. In your case, the virtual machine is not exposed. It is entirely inside the interpreter. Hence, what it is and how it works is only really of academic interest.

And frankly, so is this entire topic.

| improve this answer | |

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