Geeks With Blogs
Dynamic Concepts (in) Development Musings of TheCPUWizard

[Originally Written October 2004 - Updated September 2009]

Many people state that Microsoft .Net technology provides a "Virtual Machine" environment via the CLR. However, an examination of various definitions of Virtual Machine shows that this is not the best analogy.

For our first example definition, let us look no further than Microsoft's own site:

Virtual Machine: A software-implemented computer that emulates a complete hardware system in a self-contained, isolated software environment and runs its own operating system.

Clearly this does not apply so lets break down the parts of  "a complete hardware system". The three major categories of devices that make up a system are: Memory (some type of storage),  Processing, and Input/Output.

When a program written in any language uses the Microsoft Implementation of the CLR, it directly utilizes the actual memory presented by the underlying system, All processing is done using native instruction execution on the underlying processor, and all Input/Output is accomplished via the device (Drivers) provided by the underlying operating system.

So, while it is possible (and there are projects attempting to reach this goal) to implement the CLR as a Virtual Machine. It is clear that the current Microsoft implementation provides none of these features.

The feature that the CLR provides is that there is an intermediate stage where the source code has been reduced from the original form into a well defined set of intermediate instructions that are independant of any specific target environment. Additionally a rich library (the BCL) is provided for addressing many common constructs and providing additional abstractions over lower level functionallity.

But remember this intermediate code NEVER executes. It undergoes a second compilation phase to become pure native instructions.

This process actually has a long history. Long, long ago [1970's 1980's] it was quite common for high level language compilers to emit (either by default or as an option) assembly language SOURCE rather than object code. This output could then be copies to various target machines (with differences in capabilities) and run through the assembler (often with differing configurations or external linkages) to produce an executable that was specifically tailored to the targeted machine.

Although the mechanics are different this is completely analogous to what happens with a CLR based program.

The result is that while .Net (the CLR) does provide a level of abstraction from the actual executable code, it does not meet the criteria for a "Virtual Machine".

Posted on Thursday, September 24, 2009 7:04 PM Contrary Views | Back to top

Comments on this post: The CLR does not a Virtual Machine Make...

# re: The CLR does not a Virtual Machine Make...
Requesting Gravatar...
Valid points all - I agree that the CLR as currently implemented in .NET is not a virtual machine. Then again, my Xeon 5200 doesn't really execute x86/x64 instructions either. It "compiles them on the fly" into the micro-instructions of the CPU core, so the distinction is wearing pretty thin at this point. Could a hardware CPU be built that directly executes MSIL? Maybe. Could not the CLR then be described as a virtual implementation of that hypothetical CPU?
Left by Carl Daniel on Sep 24, 2009 8:19 PM

# re: The CLR does not a Virtual Machine Make...
Requesting Gravatar...
Carl, you are 100% correct that modern CPU architectures really do blur the line. I remember quite well when a given OpCode could be directly correlated to which logic gates would turn on/off/toggle. There were even times where one would "freeze the clock" and use a voltmeter to meausre internal states trying to diagnose a misbehaving CPU. [This was back in the early/mid 1970's].

Your scenario of a CPU that directly executed MSIL, and then viewing the CLR as a virtual implementation of that hypothetical CPU is quite reasonable. One would have to see how memory, devises and low level services were implemented to see if they all combined to form a virtual MACHINE.

One "test" that I like, is to examine if a process running "outside" the environment being considered a virtual machine can directly manipulate conditions "inside" the environment.

For example, a host process on a physical machine running Hyper-V (or VmWare,Citrix, can not attach as a LOCAL debugger to a process inside a guest. From the point of view of the host, the guest is a completely separate machine [a black box].

On the other hand, it is quite common to be outside the CLR environment, and attach a debugger [even coredbg] to a CLR hosted process and examine the state of memory, registers, etc. There is not a "boundary" that differentiates the two environments as "different machines".
Left by TheCPUWizard on Sep 25, 2009 4:43 AM

# re: The CLR does not a Virtual Machine Make...
Requesting Gravatar...
Actually I think Microsoft's definitiaon is too narrow. By that definition things commonly thought of as virtual machines, e.g.the Z-machine and Java wouldn't be either. To be fair I imagine the Microsoft definition (without looking it up directly) was probably referring to VM's in the contect of Virtual PC or some other virtualization software. We can think of these as 'complete' virtual machines.

Still I think there is room in the concept to allow 'partial' virtual machines (virtual CPU's perhaps?) such as the Z-machine. The issue of whether or not the bytecode is excuted or re-compiled is irrelevant. There exist both bytecode interpreters and JIT compilers for Z-machine code and this should be considered nothing more than an implementation detail. In the same respect, the CLR would be a partial virtual machine specification. It is possible to have interpreted or jitted implementations and which is actually chosen is irrelevant to the specification itself.
Left by Mike Greger on Sep 29, 2009 3:06 PM

# re: The CLR does not a Virtual Machine Make...
Requesting Gravatar...

Thank you for your post. Rather than complicate the meaning of the word "Machine", why not just refer to those cases as Virtual Processors (or Virtual CPU's)???

Going all the way back to the virtual machines of the 1970's (and earlier) on Mainframes, there has always been a clear demarcation between the virtual and physical [i.e. one can not POSSIBLY directly access the other]

Also note that I am not saying that the CLR could not be impllemented as a complete virtual machine. But when the result is a normal process executing native code that can be debugged [and "hacked"/attacked] by any other process that is running on the physical machine, the boundary [and the isolation] simply does NOT exist.
Left by TheCPUWizard on Sep 29, 2009 8:16 PM

# re: The CLR does not a Virtual Machine Make...
Requesting Gravatar...
They are different things (by degree, rather than design), but I think we are stuck with the terminology now.

I don't think the isolation argument is valid though. While under normal circumstances isolation exists between the host/guest machines, attacks have appeared which can penetrate this on many popular virtual machine software packages. In the end the guest machine's code still has to execute on the physical cpu at some point. I don't see how, for instance, attaching a debugger to a Virtual PC process and trying to determine what the guest PC is doing is any different than attaching a debugger to a Z-machine interpreter and trying to figure out what the Z-code is doing. They are both isloated by a level of abstraction, but if we have enough information about the VM software, we can see through it. Hardware assisted virtualization doesn't really even count since if it is separated in hardware it really isn't a true virtual machine in the strictest sense, and doesn't even fit Microsoft's definition. I guess we could call them 'shared machines'. Hehe.
Left by Mike Greger on Sep 30, 2009 9:50 AM

Your comment:
 (will show your gravatar)

Copyright © David V. Corbin | Powered by: