Re: Garbage collection for system programming

"Simon" <sheath1@gmail.com> writes:
|>
|> Anyway, what I was wondering is this: How feasable is it to use a
|> garbage-collected language for low-level tasks like writing operating
|> systems, device drivers, memory allocation systems, and basically
|> anything else you would HAVE to write in C instead of, say, Objective
|> Caml. I know it can be done; Oberon has a GC'd kernel, I've heard
|> that an old Scheme called T had it's garbage collecter implemented IN
|> Scheme, I've heard about an OS written in Modula-3, and so on.


|> [I wouldn't worry about every byte counting so much as realtime issues
|> in device drivers and the like. I've done plenty of system programming
|> like DNS servers in perl, but never anything where there were time
|> contraints. -John]


Right. But the generalisation of 'byte counting' can be equally
important, as running out of critical resources (including cache or
TLBs) is bad news, even when it 'only' impacts efficiency.


There is no hard and fast boundary between simple space management
(e.g. a fixed size stack) and the fanciest of automatic garbage
collection. Similarly, there is a gradation from doing everything by
hand up to 'entirely transparent' automatic memory management.


Releated to this is that ALL serious operating systems have some
quite serious garbage collection facilities, it is just that they
are programmed as subroutine-like services within the system.
Let us assume that you are asking about automatic, transparent
garbage collectors.


HERESY ALERT. DO NOT READ BEYOND HERE :-)


The prime reason that garbage collectors are so unsuitable for any
resource-critical work (not just real-time, but including HPC and
much of graphics) is that they rapidly became a religion (by 1970,
to my personal knowledge). The issues are soluble, but not until
and unless dogma and nonsensical 'computer science' (the sort that
is not a science and has nothing to do with computing) is replaced
by good engineering.


The first point is that all general-purpose automatic garbage
collectors have major restrictions - for example, an alternate copy
design will necessarily allow you to use only half of your memory, and
an asynchronous one will not allow you to lock down your CPUs. It is
therefore ESSENTIAL for any resource-critical work that your garbage
collector matches your requirements.


From the days of LISP onwards, far too many programming languages and
other specifications have assumed garbage collectors, but provided no
way for a programmer to control their properties, to enquire about
them or even to have them documented! LISP, Algol 68 Fortran 90
etc. were and are all bad. This means that it is impossible to write
portable, robust or efficient programs which might even approach a
system's limits.


Operating systems are unlikely to want to work with an arbitrary
garbage collector, but are very sensitive to such properties, as other
posters have said. But they DO share with HPC work the need for
careful tuning, and many of the key aspects of tuning are memory
related. If the operating system hands those over in their entirety
to a black-box, you are potentially in trouble. Very, very deep
trouble.


This is not limited to this area. Perhaps 50% of the really nasty
problems I see are where one component of a system has assumed that
another component has certain properties, and it doesn't. If it isn't
explicitly in writing, you can't trust it - and few modern
specifications are better than hopelessly vague.


REQUIREMENT ONE: any specification that relies on a garbage collector
should include control, interrogation and documentation of essential
properties in that specification.


The last point is another garbage collector myth. They do NOT
eliminate errors caused by dangling pointers etc., but usually turn
what were programming errors into logic errors, and commonly turn bad
pointer failures into memory leaks or cases where an active pointer
refers to the wrong version of data. Well, that can be better, but it
can also mean that you don't get any hint of trouble until your system
is so badly hosed that it can't even take a dump.


I have been told that modern garbage collectors provide good
diagnostic facilities, but my attempts to look at them have left me
seriously underimpressed. None of them have enough power to help with
even the simplest 'real' failures of the sort that are likely to occur
within HPC or operating systems. For example, such problems usually
arise with highly parallel activity, after many hours or days of
running, and are rarely repeatable to order.


We don't even need to assume bugs in the garbage collector to get
chaos; bugs in the program will do equally well. When a data area is
corrupted at one end, one standard question is to ask who owns the
adjacent data area. Well, with a garbage collector, that can vary
asynchronously - and does. This is one reason that most successful,
robust uses of garbage collectors are in 'safe' languages.


REQUIREMENT TWO: you need much BETTER error detection, tracing and
diagnosis tools for garbage collectors than for explicit allocation.
They, too, should be part of the specification.

Return to the comp.compilers page.
Search the comp.compilers archives again.