A
comparison of Virtual Machines: JVM Vs CLR
Host: Madhu Gopinathan, .NET Evangelist, Microsoft India
December
26, 2002
DeepakG_[MS]: Good Evening friends!
DeepakG_[MS]: Today we have with us Madhu Gopinathan
DeepakG_[MS]: Madhu works as a .NET evangelist at Microsoft India
Madhu_MS: Hello everybody..
Madhu_MS: Good evening
DeepakG_[MS]: twe'll discuss the differences and similarities between
JVM and CLR
DeepakG_[MS]: Madhu, since we don't have any questions yet, I would
like you to start with a brief intro on virtual machines..
DeepakG_[MS]: over to you Madhu...
Madhu_MS: Yes. The idea of virtual machines and intermediate
languages has been around for quite a while (since the 70s)
Madhu_MS: For e.g. UCSD Pascal and the intermediate language:
p-code
Madhu_MS: Compiler writers thought that the idea of an
intermediate language was a good way to reduce their work to implement
compilers on multiple platforms
Madhu_MS: n+m translators from language A to intermediate
language instead of n*m translators for every hardware targetted
Madhu_MS: Java VM I would say is a commercially successful
implementation of this idea
Madhu_MS: and CLR goes some steps further by innovating
in certain key areas
Madhu_MS: Like multiple language integration, versioning
support, support for user defined metadata etc.
DeepakG_[MS]: Ok so what is so different about CLR - is it a copy
of JVM?
Madhu_MS: As I said earlier, the idea of virtual machines
and intermediate languages has been around for quite a while
Madhu_MS: CLR applies the learnings from JVM, but improves
in certain key areas: it is designed upfront for multiple language
support, versioning, etc.
DeepakG_[MS]: (Supriya): how is the block level architecture of CLR
? same as JVM ?
Madhu_MS: There are similarities and differences. The
core is a stack based machine with a set of instructions that push
to the stack, work on operands on the stack and pop from the stack
to local variables etc.
Madhu_MS: From a CLR perspective, support for versioning,
multiple languages, user defined metadata are present which are not
available in the VM
Madhu_MS: There are a number of differences between bytecode
(VM) and Intermediate Language (CLR)
Madhu_MS: I'll outline some differences w.r.to multiple
languages integration
Madhu_MS: JVM was designed to support java only and a
clear design goal for CLR was multiple language support
Madhu_MS: For e.g. Doesn't provide a way of encoding type-unsafe
features such as pointers, tagged pointers (pointers that hold type
info with the address), unsafe type conversion etc
Madhu_MS: In JVM, No support for boxing and unboxing (interaction
between value and reference types)
Madhu_MS: JVM does not allow compilers to take address
of local variables; hence it is not possible to implement byref arguments
directly.
DeepakG_[MS]: (Jai): How is the memory handling in CLR (Like garbage
collector)?
Madhu_MS: Garbage collection is provided for managed data
Madhu_MS: The garbage collector is a generational GC which
segments objects to be collected into generations
Madhu_MS: A generational collector makes some assumptions,
like
Madhu_MS: the newer the object, the shorter its lifetime
Madhu_MS: the older the object, the longer its lifetime
DeepakG_[MS]: (Mathi): does c# give pointers?!?!
Madhu_MS: I am not talking about C#, but about intermediate
language (IL)
Madhu_MS: All languages that target CLR are compiled into
IL. So IL is the key to multiple language support
DeepakG_[MS]: (Supriya): which all languages does CLR support?
Madhu_MS: There is support for more than 25 languages
today. Microsoft ships with support for C#, J#, VB.NET etc.
Madhu_MS: There are 3rd parties that provide support for
COBOL etc.
DeepakG_[MS]: (Mathi): does c# give pointers?!?!
Madhu_MS: Yes It does. Managed C++ is another one
DeepakG_[MS]: Hi Mathi, here is a quick example of pointer usage in
C#...http://www.csharphelp.com/archives/archive77.html
DeepakG_[MS]: (sowmya): Are u telling me that in the future CLR might
support Java too as a programming language?
Madhu_MS: It already does: J#
Madhu_MS: This does not mean that you can use the java
enterprise components like servlets, ejbs etc.
DeepakG_[MS]: Why JVM can't support multiple languages?
Madhu_MS: JVM was not designed for multiple languages
and is closely tied to the java object model
Madhu_MS: Other than pointer support I mentioned, there
are other features that are common in some languages that are not
supported.
Madhu_MS: For e.g. tail calls in functional programming
languages
Madhu_MS: Never indicates overflow during operations on
integer data types, which means that the time penalty may be significant
for procedures which perform intensive arithmetic in languages such
as Ada95 or SML that require overflow detection.
DeepakG_[MS]: (Abrar): Can we invoke gc from programs ?
Madhu_MS: Yes. Look for GC related methods in the System.GC
space. GC.Collect() for e.g.
DeepakG_[MS]: (Mathi): when i compile something in .net into an exe
is it a simple exe or compiles into a simple exe at runtime?!?!
Madhu_MS: It is compiled into an exe, but unlike the regular
exe, it is a managed exe
Madhu_MS: The managed exe has some smarts in it such that
when it gets executed, the CLR is loaded
Madhu_MS: The CLR uses JIT to compile the Main method
to native code
Madhu_MS: Then using the primary thread, the application
is run
Madhu_MS: Done
DeepakG_[MS]: (sowmya): Is the CLR concept same for handheld like
HPC or PPC 2002? How would it work for different hardware like ARM
or Intel based h/w?
Madhu_MS: The concept is the same, but there is a different
framework called .NET compact framework
Madhu_MS: This is specially designed for low memory devices
etc. with a subset of the classes, methods etc. available in the normal
CLR
Madhu_MS: The cool thing is that the same tool: Visual
Studio.NET can be used to develop applications that target the enterprise,
as well as that target small devices
DeepakG_[MS]: (Mathi): no i get it!! CLR complies it first at runtime
and then runs the compiled binary.. and jvm runs the code on directly
on jvm...
Madhu_MS: JVM also has JIT (just in time compiler) which
does the same thing - i.e. - compile to native code
Madhu_MS: The idea of virtual machine is not to commit
to native code immediately. For e.g, the code that you write may run
on Intel Xeon or it may run on a Intel Itanium chip: 2 different CPU
architectures, but the same code runs
Madhu_MS: By using JIT, CLR compiles for the platform
on which the application runs
DeepakG_[MS]: (DotNetGuy): hi buddies my query is that CLR is different
for windows ,Mac,Linux?
Madhu_MS: The top layer of the CLR is the same so that
you can write applications to different architectures
Madhu_MS: There is a bottom layer (platform adaptation
layer) that will be different on a per platform basis.
Madhu_MS: For e.g. look at the rotor effort for freebsd
and macintosh
DeepakG_[MS]: (Mathi): so only difference between jvm and clr is that
clr supports many diff languages!!!
Madhu_MS: Multiple language support is not a small thing:
You can write a new component in C# that inherits from a VB.NET component
or a managed C++ component
Madhu_MS: You can debug across these languages. The tool
support is excellent.
Madhu_MS: What does this buy? I think this is the ultimate
in reuse.
Madhu_MS: Apart from this, there is support for versioning
Madhu_MS: This enables side by side execution of different
versions of the same DLL
Madhu_MS: There is support for AppDomains which provides
memory isolation for multiple applications executed in the same OS
process
Madhu_MS: There is support for user defined metadata,
a key innovation that will drive model based software development
DeepakG_[MS]: (Mathi): one more thing! so clr compiles the whole code
everytime I run... is that what u are saying?!?!
Madhu_MS: Yes. It is the same in Java (using JIT or HotSpot).
Madhu_MS: If you don't like this, you can use a utility
called NGEN that is included in .NET framework.
Madhu_MS: This compiles code at installation time
Madhu_MS: CLR JIT compiles to native code the 1st time
it is run. Once native code is produced, if you run the app the next
time, the native code is used
Madhu_MS: Java VM for all practical purposes does have
JIT (except for the kilobyte VM for small devices)
DeepakG_[MS]: (sowmya): What platforms are current supported by the
CLR? For e.g. are mainframes or parallel processors supported?
Madhu_MS: There is no CLR for mainframe.
Madhu_MS: For multi processors, this is dependent on OS.
For e.g. CLR runs on Win2000 on a multi processor machine
DeepakG_[MS]: (Nilakanta): what is the difference between a CLR-executable
DLL/EXE and a normal (old) DLL/EXE?
Madhu_MS: CLR EXE/DLL is managed - in the sense that CLR
is needed to use them
Madhu_MS: The parts of this are: PE header, CLR header,
Metadata and IL code
DeepakG_[MS]: (Nilakanta): Can we run a CLR-executable DLL/EXE as
we run a normal (old) DLL/EXE
Madhu_MS: Yes. On windows, this is transparent. Just run
it. On other platforms, say Linux, Use CLIX
Madhu_MS: Done
DeepakG_[MS]: Ok guys... time for one last question
DeepakG_[MS]: (sowmya): Here is the ultimate question. When will u
have a CLR available for Linux?
Madhu_MS: CLR is microsoft implementation of CLI (Common
Language Infrastructure)
Madhu_MS: CLI has been submitted for standardization to
ECMA
Madhu_MS: Microsoft provides shared source (rotor) for
freebsd and mac
Madhu_MS: There is another effort called Mono from Ximian.
Madhu_MS: Thanks for attending the chat. I hope you got
good information
Madhu_MS: If you've any further questions, please contact
me at madhug@microsoft.com
DeepakG_[MS]: Ok folks this brings us to the end of this informative
chat session..
Madhu_MS: Thanks Again. Happy New Year!!
DeepakG_[MS]: we'll be meeting next week - which incidentally is also
next year
DeepakG_[MS]: the topic for Jan 3 chat is COM+ and how its still around
in the managed world as ServicedComponent...
