Is the CLR a virtual machine?

by

There are a lot of misconceptions here. I suppose you could think of .Net as a virtual machine if you really wanted, but let’s look at how the .Net Framework really handles your code. The typical scenario looks like this

  1. You write a .Net program in C#, VB.Net, F#, or some other compatible language.
  2. That code is compiled down to an Intermediate Language (IL), which is similar to Java’s bytecode, that is distributed to end-user machines.
  3. An end user invokes the program for the first time on a computer with the right version of .Net installed
  4. The computer sees this is a .Net assembly rather than “raw” machine code, and passes it off to the JIT compiler
  5. The JIT compiler compiles the IL to fully-native machine code.
  6. The native code is saved in memory for the life of this program execution.
  7. The saved native code is invoked, and the IL no longer matters.

There are a couple important points here, but the big one is that at no point is any code ever interpreted. Instead, you can see in step 5 that it is compiled to native code. This a huge difference than loading it into a virtual machine, for several reasons:

  1. The fully-compiled code is executed by the cpu directly rather than interpreted or translated by an additional software abstraction layer, which should be faster.
  2. The JIT compiler can take advantage of optimizations specific to the individual machine running the program, rather than settling for a lowest common denominator.
  3. If you want you can even pre-compile the code and in essence hide step 5 from the user completely.

I suppose you could call this a virtual machine, in the sense the JITter abstracts away the details of the real machine from the developer. Personally I don’t think that’s really right, because for many people, a virtual machine implies a runtime abstraction away from native code that for .Net programs just doesn’t exist.

One other key point about this whole process that really sets it apart from a “virtual machine” environment is that it’s only the typical process. If you really want to, you can pre-compile a .Net assembly before distribution and deploy native code directly to end users (hint: it’s slower in aggregate over the life of the program, because you lose machine-specific optimizations). Of course, you still need the .Net runtime installed, but at this point it’s really not much different from any other runtime API; it’s more like a collection dlls with a nice API you can link against, as you might have with the VB or C runtimes Microsoft also ships with Visual Studio. This kind of takes the IL out of the picture, making the VM moniker much harder to justify. (I say “kind of” because the IL is still deployed and used to verify the saved code, but it’s never itself touched for execution).

One other telling point is the lack of a VM process. When you run your app, there’s no common “sandbox” process that runs. Compare this with Java, where if you open the task manager when a program is running you will see a process specifically for the Java VM, and the application’s actual process is a thread inside of the sandbox created by the VM. In .Net, you see the application’s process in the Windows task manager directly.

In summary: you could say that IL + CLR + JIT together somehow make up a virtual machine. Personally I don’t think so, but I won’t argue with you if you believe that. The point I want to make is that when you tell someone that .Net runs in a virtual machine with no further explanation, the idea you are communicating to that person is “interpreted bytecode in a host process.” And that’s just wrong.

Update This answer is kind of old now, and things have changed to make .Net even less like a virtual machine. In the era of containers, cold start times can mattter a lot more, and my understanding is recent versions of .Net Core have more tools to make deploying native code — and skipping the JIT step on each startup — even easier.

More Related Contents:

  1. Deciphering the .NET clr20r3 exception parameters P1..P10
  2. Why Large Object Heap and why do we care?
  3. A definitive guide to API-breaking changes in .NET
  4. LINQ on the .NET 2.0 Runtime
  5. What are the roots?
  6. How do I detect at runtime that .NET version 4.5 is currently running your code?
  7. Resolving MSB3247 – Found conflicts between different versions of the same dependent assembly
  8. How do the .NET Framework, CLR and Visual Studio version numbers relate to each other?
  9. When is a method eligible to be inlined by the CLR?
  10. Does the .NET CLR JIT compile every method, every time?
  11. Equivalent of Class Loaders in .NET
  12. How to see JIT-Compiled code in .NET VM (CLR)
  13. How to call managed code from unmanaged code?
  14. Is it possible to get parameters’ values for each frame in call stack in .NET
  15. No AppDomains in .NET Core! Why?
  16. Get Current .NET CLR version at runtime?
  17. Handling Dialogs in WPF with MVVM
  18. .NET Format a string with fixed spaces
  19. What is the difference between .NET Core and .NET Standard Class Library project types?
  20. Why is the first WCF client call slow?
  21. .NET DateTime.Now returns incorrect time when time zone is changed
  22. Asynchronous iterator Task
  23. How to improve the Performance of FtpWebRequest?
  24. Web Services — WCF vs. ASMX (“Standard”)
  25. How to make a .NET application “large address aware”?
  26. Should I make a DateRange object?
  27. WCF error: The caller was not authenticated by the service
  28. What is the best way to read GetResponseStream()?
  29. App.config connection string relative path
  30. Why doesn’t doubleclick event fire after mouseDown event on same element fires?

Leave a Comment