Is the CLR a Virtual Machine?

A reader recently asked me if the CLR is a Virtual Machine or not. An interesting question that comes up frequently enough that I think it is worth addressing here.  I asked around the usual suspects on the CLR team and got some of their impressions. 


As you may know we typically refer to the CLR as an Execution Engine rather than a virtual machine.  Some of the motivation to use the term Execution Engine was because at the time we shipped V1.0, the term Virtual Machine was most commonly used to refer to Java’s VM, even though there is a long history of other Virtual Machines.    Now there are a large number of terms various folks are using to refer to environments such as Java and the CLR:  VM, EE, VEE, MRE and MRTE and even a conference dedicated to the topic.


Now, the term Virtual Machine has come to be a general term that describes abstract execution environments such as the CLR, the JVM, the Smalltalk VM, etc.  The term “virtual machine” is really a much older term from the hardware world (IBM’s virtualization of the 360 was the first, I believe, in the 1960s) that used to mean a software/hardware emulation of the underlying machine to accomplish the same sort of stuff that Microsoft does with VirtualPC .  However the term Execution Engine refers to the implementation of a completely different machine (an “IL Machine” on top of an x86).  That’s the same thing the Pascal PMachine did (PCode on top of lots of hardware) for example… and it is the same thing both the CLR and the JVM do.


So the bottom line is that the CLR and JVM are in the same class whether you call that class of software “virtual machines” “execution engines” depends on your perspective. 



Comments (7)
  1. N says:

    Thanks for the answer. This question seems to depend largely on how to define the term Virtual Machine. If we say virtual machine is just the abstraction in term of instructions, we can say VB, Pascal, Smalltalk, VBScript, JavaScript have VM (Probably, Gates’ GWBasic even contains a VM Implementation). In broader interpretation, can we consider that language that we use "abstraction of instructions"? If so, even C, C++ are the implementation of VM in some sense but I wouldn’t go that far.

    In my view, those stuff are more like execution engine, bytecode interpreter, jit compiler more than virtual machine. Virtual Machine should really isolate hardware from the language. Java did pretty well in that sense while .NET allows users/developers to "hack" into the underlying hardware more directly like memory addressing/COM. I also think that there are some differences in more detail in terms of security implementation that might be worth mentioned.

    Really, what is really the fine line to decide whether it’s VM or not?

  2. mschaef says:

    "However the term Execution Engine refers to the implementation of a completely different machine (an “IL Machine” on top of an x86). That’s the same thing the Pascal PMachine did (PCode on top of lots of hardware) for example… and it is the same thing both the CLR and the JVM do."

    There is one big difference between the JVM and CLR:

    "picoJava Microprocessor Cores are uniquely designed processor cores that natively execute Java bytecode as defined by the Java Virtual Machine (JVM). "

    That would make a JVM a software implementation of a particular hardware architecture. Also, since Java bytecodes are typed, compared to the polymorphic bytecodes used by the MSIL, it’s a lot more plausible to do Java in hardware than the CLR. This seems like a good way to distinguish between a "Virtual Machine" and a "Execution Environment".

    That said, given the history of the term in Java, Smalltalk, and other dynamic languages, I’d use the term VM for both the JVM and the CLR.

  3. Bob Riemersma says:

    Considering all the hooks back into the "real" machine, I don’t think the term VM applies. It has more of the feel of a "host and execution environment" a la WSH or IE or something for script and ActiveX components. Or a VB program compiled to p-code.

    But I suppose this is more hair splitting.

  4. Mark Mullin says:

    I’ve always thought that it depends on your perspective – I know the Smalltalk kernel better than .net, but

    1) From the point of view of the application, it’s a pure virtual machine – it implements a virtual instruction set that is disjoint from the native processors instruction set, and performs the mapping via software

    2) From the point of view of the high level kernel it’s a mixed bag

    -a Some stuff is intercepted immediately and jitted, i.e. there is a virtual machine, but it ain’t an execution machine per se, it’s a translator

    b- Some stuff is hardwired, i.e. particular opcodes in the virtual machine are fundamentally trapdoors into the native system

    c – and some stuff really is virtual, that is, it’s interpreted by the core logic and the instruction set is truly disjoint

    I see these machines as hybrids – a true virtual machine is one that realizes its entire instruction set through a software implementation, and interprets some kind of low level language at runtime to sequence virtual operations for processing – jitting doesn’t fall into this class because it’s effectively a transformation of representation followed by native execution, whereas the true virtual machine is a 1:n straight execution, where each virtual instruction corresponds to n _direct_ operations on the physical machine.

  5. Project Vismaya [Update]

  6. I have recently put together a set of slides about LIL (Low-level Intermediate Language) and gave a talk…

Comments are closed.

Skip to main content