Re: a .NET alternative (GJC et al)

[Fergus Henderson <fjh at cs dot mu dot oz dot au>]

On 27-Jul-2001, Tom Lord <lord@regexps.com> wrote:
> 
> I think it is widely recognized, nowadays, that a good approach to
> implementing high level languages is to build a common run-time system
> on which they run.  The run-time system provides the low-level
> functionality these languages have in common, and is a foundation upon
> which interoperability between languages can be built.

Yes.  This has been the case for a long time, actually;
what is changing is the details of what goes in the run-time system.

On Unix systems, C provided the lowest common denominator,
and other language implementations generally reused the
C language runtime and often used compatible calling conventions.
The services offered by the runtime in this case are

	- a stack
	- a manually-deallocated heap
	- some library routines for I/O, etc.
	- more recently, Posix threads
	- even more recently, exception handling (in libgcc)

The difference with the JVM and the CLR is that additional services
are included in the runtime:

	- exception handling
	- garbage collection
	- run-time type information
	- run-time stack walking
	- architecture-independence (via an intermediate bytecode)
	- etc.

> I'm concerned about the run-time systems we currently use.  Here are
> two reasons that indicate some of my thinking: (1) we seem to have
> systems that rely on conservative garbage collectors, which makes
> these implementations needlessly unreliable;

Needless *inefficiency* is a more significant problem, IMHO.

But you're right that lack of accurate GC is a problem.
The difficulty there is that accurate garbage collection requires
co-operation between the compiler and the run-time system, and GCC
doesn't have any support for it.

Could anyone summarize the current state of accurate garbage
collection support in GCC?  I remember seeing remnants of previous
attempts lying around in the code at various times, but they seem
to have been expunged, and accurate GC support isn't listed in
the "Projects" section on the web site. 

Does the infrastructure for the new exception handling support help
with accurate GC?  Judging by past failures, and the magnitude of the
task, accurate GC support in GCC seems to me to be too difficult to do
all at once, at least for ordinary mortals.  Is accurate GC support
something that can be achieved incrementally in GCC, like the way the
target-specific #ifdefs have been going away?  Or is it a hopeless
task, one that can only be successfully accomplished by writing a new
compiler from scratch?

> (2) we don't seem to have
> any projects to build a common run-time system, designed to support
> several languages (we have Guile, designed to be a multi-lingual
> Scheme, but that's not quite the same thing).

> The opportunity is to build a new Free Software run-time system,
> providing a precise collector, and support for multiple languages.
> 
> The choices are (1) whether to re-implement the specifications offered
> by Microsoft, or try to implement something better, and (2) whether to
> tie the implementation of a new run time system to a specific compiler
> (GCC, presumably) or try to build something more portable.

Note that implementing something better could mean starting
from scratch, or it could mean adapting some existing project.
There are a few somewhat related projects (C--, ORP, ...)
that are not exactly intended as multi-language run-time systems,
but which may be a better base than starting from scratch.

C-- is an attempt to provide an interface by which language front-ends,
compilers, and runtime systems can communicate and co-operate to
support features like GC, exception handling, etc.

> But I've always thought that Free Software was about more than just
> cloning Microsoft software.  I like to believe that Free Software is
> also about creatively exploring new ideas and having the kind of fun
> that comes from trying to build something "better".  So I'm interested
> in a different branch of the run-time system design space.
> 
> In particular, I've been working towards a run-time system in C, not
> C#, supporting multiple high level languages, and providing a a
> precise garbage collector (along with lots of other nice features).

Looking at the web site, it seems that you've been working on the
standard library, rather than the other services of a run-time,
such as garbage collection, etc.

Unfortunately it's the accurate GC, RTTI, exception handling, etc.
that are the hard bits.

If you do want to design a new library, it's crucial to decide exactly
which features you're going to have in the runtime system
(e.g. will it support exception handling?) *before*
designing the library.

Working on the standard library is understandable, and in some ways
admirable, but IMHO not maximally useful at this stage, since we
already have an adequate C standard libraries.  Certainly it would be
possible and useful to write a better one, but most such improvements
can be made by extending the existing library (e.g. libiberty) rather
than completely replacing it.  There is a huge installed base of
existing code which uses the existing library, and that is not going to
go away anytime soon; indeed, I doubt it will go away even in my
lifetime.

A new standard library will only be accepted if it has compelling benefits.
Minor incremental improvements over the existing C/Unix standard library
are not enough to overcome the advantages of the installed base.
For a new standard library to be accepted, I think it needs to comes with a
run-time that provides additional compelling benefits, such as type
safety, exception handling, garbage collection, and thread safety,
which you can't take full advantage of when using the old standard library.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.