What's the difference between the inner workings of Java's JVM and .NET's CLR?

Question

What's the difference between the inner workings of Java's JVM and .NET's CLR?

Perhaps a starting point would be, are they basically the same thing in their respective environments (Java > JVM > Machine code) (C# > CLR > IL).

---

Update: Several people have alluded to the points I was trying to cover:

1. Garbage Collection
2. Boxing/Unboxing
3. JIT debugging
4. Generics/Templates
5. Please feel free to suggest other good topics that differentiate the two.

@George Mauer - this sounds very interesting:

Already posted this once but here is a series of interviews with c# chief language designer Anders Hejlsberg.

Answer 1

The CLR and JVM have goals and philosophies that differ more than you might think. In general, the JVM aims to optimize more dynamic, higher-level code while the CLR gives you more low-level tools to do these kinds of optimizations yourself.

A good example is stack allocation. On the CLR you have explicit stack allocation of custom value types. On the JVM the only custom types are reference types but the JVM can convert heap allocations to stack allocations in certain circumstances through Escape Analysis.

Another example. In Java, methods are virtual by default. On C# at least, they are not. It is much more difficult to optimize virtual method calls because the code that gets executed at a given call site cannot be determined statically.

Under the hood, their execution systems are quite different. Most JVMs (in particular, Hotspot) start out with a bytecode interpreter and only JIT-compile parts of the code that are executed heavily e.g. tight loops. They can also re-compile these over and over each time using execution statistics collected from previous runs to drive optimizations. This allows more optimization effort to be applied to the parts of the program that need it most. This is called adaptive optimization.

The CLR compiles everything up-front only once. It does fewer optimization both because it has more code to compile and so has to be fast and because it doesn't have any statistics of the actual execution paths taken to feed into its optimizations. This approach does have the very significant advantage of allowing you to cache compilation results across processes, which CLR does but JVM does not.

A large percentage of the Hotspot JVM code is dedicated to these adaptive optimizations and they are what put Java in the same performance ballpark as native code for most general purpose computation in the early 2000s. They are also what makes the JVM a decent target for dynamic languages. I'm excluding here the more recent developments of the Dynamic Languages Runtime and invokedynamic as I don't know enough about the DLR.

Answer 2

There differences in garbage collection as well. JVM uses Copying collector and Mark and sweep. .NET user Copying collector and Mark and compact (Much harder to implement).

Also type erasure mentioned by Flyswat is important. JVM doesn't have a clue about generics and everything is object and associated perf. penalty of boxing and unboxing. Also reflection won't give you generic information. CLR supports generics natively.

Answer 3

As far as I know, .Net CLR still has much more flexible and powerful Code Access Security built into the runtime, allowing much finer grained permissions and execution policy.

Answer 4

One essential difference is that the JVM is portable across platforms and runs on Linux, Macintosh, and many cell phones and embedded devices.

CLR runs on Microsoft supported platforms with the Mono project providing partial support of older versions of CLR on a few more.

Internally this means the JVM's performance will vary on those different platforms based on capabilities provided by the platforms themselves.

Answer 5

Miguel de Icaza mentions here:

Seasoned industry programmers will notice that the above is very much like Java and the Java VM. They are right, the above is just like Java.

The CIL has one feature not found in Java though: it is byte code representation that is powerful enough to be used as a target for many languages: from C++, C, Fortran and Eiffel to Lisp and Haskell including things like Java, C#, JavaScript and Visual Basic in the mix.

I wish I had the time to go in more detail, but for the sake of this argument, the above will suffice.

The comments go into some details, though, like tail call optimizations. Lot have changed since 2002 though - both CLR and JVM now have multiple languages targeting it. But nonetheless worth a read.

Answer 6

As Vinko said, the full details are way beyond the scope of a forum post. The differences/similarities boil down to this:

They are both a runtime environment "sandbox" that include a "just-in-time" compiler to translate program instructions in an intermediate language (MSIL or ByteCode) to native machine code and provide automatic memory management (garbage collection). Sitting on top of the respective runtime environments are a set of class libraries that provide higher level abstractions to developers to simplify development tasks.

The internals of how those runtime environments are actually implemented are, for the most part, proprietary to Microsoft and Sun. The algorithms used by the garbage collection systems, for example, while probably similar in technical functionality are different in implementation.

Answer 7

This should be a great thread.

One of the biggest differences is between the CLR and JVM is the CLR"s native integration of generics.

Java instead removes the generic types and the JVM can only work with objects by autoboxing the objects it appears to be pseudo generics.

Answer 8

From here. I couldn't have said it better (Well, with the exception of a flame war, this is a flameless place :-) ).

Hello,

Responding to your question seems fraught with peril by starting a flame war, so I'll proceed cautiously.

There are a number of fundamental technical similarities between the Java Runtime and the Common Language Runtime, including garbage collected memory, an intermediate language (Microsoft IL versus Java ByteCode), core system libraries, and support for fairly high level languages, code security, and deployment.

However, each of these 'similar' areas also have a number of sizable and small differences, and it's beyond the scope of a simple Forum post to describe most of them.

I would suggest asking a more targetted question about any of the various runtime features and component areas (e.g. memory management, compilation, system libraries, security, etc.) and then we can provide a more targetted response (e.g. a blog, a technical article, or some books).