Re: following up on speed

[address@hidden]

   From: Daniel Weinreb <DLWeinreb@attbi.com>
   >> On a sort-of related note, I've wondered for a long time why garbage
   >> collection isn't provided as an operating system service instead of 
   >> having to be re-implemented for every single language that needs it

   It's my impression that to have a system-wide cross-language GC, the
   languages would all have to agree to follow certain conventions at runtime,
   such as rules about which registers are used for what purpose at all times,
   and about conventions for telling the GC when it can roll back the PC in
   certain ways, etc.. If so, that's a more stringent requirement that's hard
   to meet in these days of mix-and-match software. Olin Shivers, can you
   comment?

Yep. I have fantasized about cross-language GC-as-an-OS-service for decades.
But it always comes down to the run-time system and representations, and these
vary wildly from language implementation to language implementation. If you go
multi-language, you are forced into a least-common-denominator approach, which
forces you to the l.c.d. technology, such as conservative, non-copying
collectors, because you can't rely on much when you're working with C and gcc.

Suppose you defined a higher-level contract for run-time systems -- fixed
a representation for data that a GC could manage, and required all compilers
to respect it. Then you could get somewhere. But you'd have to write a
whole new suite of compilers for languages like C and Java that respected
these representations. And I'd have to really sit down and think about ANSI
C to convince myself that you could do a GC-safe ANSI C; people probably
would break it with the coding style used for most C, in terms of pointers
and casts and so forth. And you'd constrain the implementations of the 
Scheme and ML and Java systems, as well, so you better come up with a 
representation that you are *really* going to be willing to live with.

The upside is that everything gets along with everything else, and can
interact in a very tightly coupled way.

GC is fundamentally an extremely global, non-modular thing -- it gets its
fingers into every corner of the system. It has to, in order to understand
who is using what. The payoff for this is modularity for the client software.
Modules can export data w/o having to have their interfaces complicated with
the issue of who is responsible for freeing the data structure. This really,
really simplifies module interfaces. And thin interfaces between complex
modules is what software engineering is all about. So I view GC as a
fundamental technology for modularity. Which, to repeat my original sentence,
is tied to it being so non-modular itself.
    -Olin