Re: Alternative to C for system programming

On Feb 9, 12:21 pm, rem6...@xxxxxxxxx (robert maas, see http:// wrote:
From: "W Karas" <wka...@xxxxxxxxx>
Modula-3 is designed as a modern (OO, GC, etc) system programming language.
Does Modula-3 have two kinds of pointers, one that points to
dynamically allocated objects, and another that is ignored by
garbage collection, and is covertable to/from an intergal type?

IMO you've prejudged possible solutions by stating the one and only
solution at the start instead of considering alternatives. For
example, instead of two kinds of pointers (GC/nonGC), there could
be blocks of memory that are GC and nonGC, with a table that tells
which is which, and a configuration file to determine the initial
state of the block-table early in booting, and system calls to
change this table later during booting and during normal operation
including hot updates to the OS.

I was assuming we would want to use a GC implementation that
defragments (completely), not just frees. Without this requirement,
your approach would work. But having two types of pointers would
still make GC faster, as you'd only have to examine the heap

When I hear "systems programming language with GC" I can't help
but be suspicious of a bait-and-switch. Seems like a tall order to
design a kernel that has GC running yet can still meet tight
minimal response times to system events. That is to say,
if a language has GC, but GC is typically disabled when doing
systems programming with the language, it's not very meaningful
to call it a systems programming language with GC.

It seems to me that so long as allocation/dealloction aren't done
right in the middle of a time-dependent event, such as serving an
interrupt on a device such as a rotating disk, there shouldn't be
any problem. Just make sure your disk buffer or whatever is
allocated *before* you start the disk-read operation, so by the
time an interrupt happens the buffer is just sitting there
instantly available as needed. Most other tasks don't really suffer
horribly if there's an occasional long pause (on the order of one
second) in the middle of an operation. For example, user's program
wants to write a new file, but directory needs GC before the system
can be sure whether expanding the directory will really be needed
to fit in one more file handle, so user's program experiences a
brief pause, no longer than more common pauses due to system gotten
really busy with fifty other users or a burst of spam coming into
the SMTP server.

For low-latency event handling, you wouldn't want to do dynamic
allocation of any sort, regardless of whether the memory would
be expicitly or implicitly freed. But it seem possible that, in
some hypothetical application, there could be "medium-
latency" event handling, where dynamic allocation would
be fast enough only if it were not blocked by a GC sweep.