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

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

<hr>

<p><strong>Update:</strong>  Several people have alluded to the points I was trying to cover:</p>

<ol>
<li>Garbage Collection </li>
<li>Boxing/Unboxing</li>
<li>JIT debugging </li>
<li>Generics/Templates</li>
<li>Please feel free to suggest other good topics that differentiate the two.</li>
</ol>

<p><a href="https://stackoverflow.com/users/5056/george-mauer">@George Mauer</a> - this sounds very interesting:</p>

<blockquote>
  <p>Already posted this once but here is a <a href="http://www.artima.com/intv/anders.html" rel="nofollow noreferrer">series of interviews</a> with c# chief language designer Anders Hejlsberg. </p>
</blockquote>

[{'answer_id': 59187, 'author': 'Vinko Vrsalovic', 'author_id': 5190, 'author_profile': 'https://Stackoverflow.com/users/5190', 'pm_score': 3, 'selected': False, 'text': '<p>From <a href="http://social.msdn.microsoft.com/forums/en-US/clr/thread/38223155-c07c-472a-8903-6cdaf5f110ea/" rel="nofollow noreferrer">here</a>. I couldn\'t have said it better (Well, with the exception of a flame war, this is a flameless place :-) ).</p>\n\n<blockquote>\n  <p>Hello,</p>\n  \n  <p>Responding to your question seems\n  fraught with peril by starting a flame\n  war, so I\'ll proceed cautiously.</p>\n  \n  <p>There are a number of fundamental\n  technical similarities between the\n  Java Runtime and the Common Language\n  Runtime, including garbage collected\n  memory, an intermediate language\n  (Microsoft IL versus Java ByteCode),\n  core system libraries, and support for\n  fairly high level languages, code\n  security, and deployment.</p>\n  \n  <p>However, each of these \'similar\' areas\n  also have a number of sizable and\n  small differences, and it\'s beyond the\n  scope of a simple Forum post to\n  describe most of them.</p>\n  \n  <p>I would suggest asking a more\n  targetted question about any of the\n  various runtime features and component\n  areas (e.g. memory management,\n  compilation, system libraries,\n  security, etc.) and then we can\n  provide a more targetted response\n  (e.g. a blog, a technical article, or\n  some books).</p>\n</blockquote>\n'}, {'answer_id': 59206, 'author': 'FlySwat', 'author_id': 1965, 'author_profile': 'https://Stackoverflow.com/users/1965', 'pm_score': 3, 'selected': False, 'text': '<p>This should be a great thread.</p>\n\n<p>One of the biggest differences is between the CLR and JVM is the CLR"s native integration of generics.</p>\n\n<p>Java instead removes the generic types and the JVM can only work with objects by autoboxing the objects it appears to be pseudo generics.</p>\n'}, {'answer_id': 59240, 'author': 'Scott Dorman', 'author_id': 1559, 'author_profile': 'https://Stackoverflow.com/users/1559', 'pm_score': 0, 'selected': False, 'text': '<p>As Vinko said, the full details are way beyond the scope of a forum post. The differences/similarities boil down to this:</p>\n\n<p>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.</p>\n\n<p>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.</p>\n'}, {'answer_id': 59415, 'author': 'Binil Thomas', 'author_id': 3973, 'author_profile': 'https://Stackoverflow.com/users/3973', 'pm_score': 1, 'selected': False, 'text': '<p>Miguel de Icaza mentions <a href="http://www.linuxtoday.com/news_story.php3?ltsn=2002-02-06-011-20-OP-GN-MS&tbovrmode=3" rel="nofollow noreferrer">here</a>:</p>\n<blockquote>\n<p>Seasoned industry programmers will notice that the above is\nvery much like Java and the Java VM.   They are right, the above\nis just like Java.</p>\n<p>The CIL has one feature not found in Java though: it is\nbyte code representation that is powerful enough to be used as a\ntarget for many languages: from C++, C, Fortran and Eiffel to Lisp\nand Haskell including things like Java, C#, JavaScript and Visual\nBasic in the mix.</p>\n<p>I wish I had the time to go in more detail, but for the sake\nof this argument, the above will suffice.</p>\n</blockquote>\n<p>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.</p>\n'}, {'answer_id': 96913, 'author': 'Brian', 'author_id': 8959, 'author_profile': 'https://Stackoverflow.com/users/8959', 'pm_score': 2, 'selected': False, 'text': "<p>One essential difference is that the JVM is portable across platforms and runs on Linux, Macintosh, and many cell phones and embedded devices.  </p>\n\n<p>CLR runs on Microsoft supported platforms with the Mono project providing partial support of older versions of CLR on a few more.</p>\n\n<p>Internally this means the JVM's performance will vary on those different platforms based on capabilities provided by the platforms themselves.</p>\n"}, {'answer_id': 1919233, 'author': 'codekaizen', 'author_id': 58391, 'author_profile': 'https://Stackoverflow.com/users/58391', 'pm_score': 0, 'selected': False, 'text': '<p>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.</p>\n'}, {'answer_id': 2117199, 'author': 'Fakrudeen', 'author_id': 256717, 'author_profile': 'https://Stackoverflow.com/users/256717', 'pm_score': -1, 'selected': False, 'text': "<p>There differences in garbage collection as well. \nJVM uses Copying collector and Mark and sweep. .NET user Copying collector and Mark and compact (Much harder to implement).</p>\n\n<p>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.</p>\n"}, {'answer_id': 15861994, 'author': 'Ramon', 'author_id': 199288, 'author_profile': 'https://Stackoverflow.com/users/199288', 'pm_score': 2, 'selected': False, 'text': "<p>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. </p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n"}]
['https://Stackoverflow.com/questions/59175', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/4575/']