Technical Overview of the Common Language
Runtime
(or why the JVM is not my favorite execution
environment)
Erik Meijer and Jim Miller
{emeijer,jsmiller}@microsoft.com
Abstract
In the last few years many language researchers have moved to the JVM as the
delivery vehicle for their languages. Although the JVM is a great target for the
JavaTM programming language, it is not necessarily a good platform for other lan-
guages, especially languages that require semantic features that do not appear in
JavaTM . In this paper we compare the JVM with the new Microsoft .NET Common
Language Infrastructure (CLI), which has been designed from the ground up to be
a multi-language platform.
1 Introduction
The ideas of virtual machines, intermediate languages and language indepen-
dent execution platforms have fascinated language researchers for a long time.
Well known examples include UNCOL [6], UCSD P-code [22], ANDF [20],
AS-400 [24], hardware emulators such as VMWare, Transmeta CrusoeTM [28],
binary translation [25], the JVM [19], and most recently Microsoft’s Common
Language Infrastructure (CLI) [2].
There are several reasons why people are looking at alternative implementation
paths for native compilers:
Portability By using an intermediate language, you need only n+m transla-
tors instead of n∗m translators, to implement n languages on m platforms.
Compactness Intermediate code is often much more compact than the orig-
inal source. This was an important property back in the days when memory
was a limited resource, and has recently regained importance in the context
of dynamically downloaded code.
Preprint submitted to Elsevier Preprint
8 June 2001
Efficiency By delaying the commitment to a specific native platform as much
as possible, you can make optimal use of the knowledge of the underlying
machine, or even adapt to the dynamic behavior of the program.
Security High-level intermediate code is more amenable to deployment and
runtime enforcement of security and typing constraints than low level bina-
ries.
Interoperability