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

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).

Answer 2

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 3

Already posted this once but here is a series of interviews with c# chief language designer Anders Hejlsberg. Though mostly talking about the differences between C# and Java he does dive into differences between the virtual machines as well.

Answer 4

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 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

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 7

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 8

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.