.NET CIL compared to JVM bytecode
843811Sep 30 2003 — edited Oct 27 2003hi,
I've been reading this article
http://genamics.com/developer/csharp_comparative.htm
which compares aspects of java and C# (although it is now quite old).
am interested in finding out more about the differences between C# bytecode and JVM bytecode.
does anyone know what properties of C# bytecode enable the claims below?
thanks,
asjf
This is quoted verbatim from http://genamics.com/developer/csharp_comparative.htm#24
Originally virtual machines had an interpreter which converted a stream of byte-code instructions to machine code on the fly, but this dreadfully slow process was never appealing to the performance conscious programmer. Today most Java Virtual Machines use a Just-In-Time compiler which basically compiles to machine-code class skeletons just before they enter scope and method bodies just before they are executed. It is also possible to convert a Java program to assembly language before it runs to eliminate the overhead in start-up time and memory of a Just-In-Time compiler. As with compiling a Visual C++ program, this process does not necessarily remove the program's dependence on a runtime. The Java runtime (also covered by the term "Java Virtual Machine") will handle many vital parts of the programs execution such as garbage collection and security. This runtime is referred to as a managed execution environment.
Though somewhat obscured by terminology, the basic model .NET uses is the same as described above, though it was built to never use intepreting. Important improvements .NET will offer will come from the IL design itself, since the only way Java can match such improvements is by changing the byte-code specification which would generate serious compatibility issues. I don't want to discuss in detail these improvements - it should be left to those rare developers who understand both byte-code and IL-code. For the 99% of developers like myself who realistically aren't going to be studying the IL-Code specification, here are some of the design decisions for IL which are intended to improve upon byte-code:
To provide greater type neutrality (helps implementing templates)
To provide greater language neutrality
To always be compiled to assembly language before executing, and never interpreted
To allow additional declarative information to be added to classes, methods, etc.,