Programming on Unix and automatic memory management

April 23, 2023

Due to the pervasive influence of C, Unix is commonly thought of as a programming environment of manual memory management; you program Unix in C and C requires manual memory management. Except that I maintain this is somewhat of an illusion. From the days of V7 Unix onward (if not earlier), a substantial amount of Unix programming has always been done in languages with automatic memory management. It's just that we called this programming "shell scripts", "awk", "make", and so on.

(Then later all of these programming environments got slammed together to create Perl. People don't necessarily like Perl, but I think it's pretty undeniable that it had a substantial presence in 1990s era Unix programming.)

This isn't just an aspect of general Unix development after all sorts of people got their hands on it (and created things like Perl). In Bell Labs Research Unix and then Plan 9, I think pretty much every new language (or language) created for and on Unix was one with automatic memory management. One exception is Plan 9's Alef, but no less a person than Rob Pike has said that one reason for Alef's failure was its lack of automatic memory management.

(Another exception is C++, although that didn't quite come out of the core Research Unix environment. Obviously C++ has been highly successful.)

In short, programming with automatic memory management has been a part of Unix from Bell Labs onward. It's not some new intruder; it's a normal part of Unix, and the creators of Unix were clearly not philosophically opposed to automatic memory management under any circumstances.

PS: Some of the automatic memory management is forced in various ways; for example, a declarative language like "make" doesn't really have room for manual memory management. But I can somewhat imagine a version of awk that required you to do manual handling of some things. How difficult it is to imagine a version of awk with any form of manual space management suggests why it has its actual form.

(This elaborates on a Fediverse post, and was sparked by this.)


Comments on this page:

«Due to the pervasive influence of C, Unix is commonly thought of as a programming environment of manual memory management; you program Unix in C and C requires manual memory management.»

It may be an issue of terminology, but C with malloc(3) does automatic memory management! The programmer simply asks for N bytes, and automatically N bytes get found somewhere and marked as allocated. Manual memory management happens when programmers must allocate memory as in specifying the address range for every object.

What C does not have is implicit memory reclaim, programmers are expected (but not required) to explicitly use free(3) to indicate a reclaimable object. Then the memory automatically allocated to that memory object might be automatically freed.

There is a different between automatic and implicit memory management; for example in some other languages memory allocation is not merely automatic as in C but also implicit when creating a new instance of some type/class, while in C memory allocation, even if automatic, must be explicit before initializing the resulting memory object with a instance of some type/class.

Terminology leads a lot of people into conceptual confusion unfortunately (e.g. the definition of "object" in C and C++), and the confusion between automatic/manual and explicit/implicit memory management is one of the two most popular ones (the other is the confusion between "strong typing" and "manifest typing" aka "type constraints").

By Orev at 2023-04-24 11:13:06:

This is a unique perspective and I really like it. This is a very cool idea that I hadn’t thought about this way before. It’s essentially saying that because so many functions in a script are actually external programs, memory is reclaimed automatically when that function completes/returns. That seems far more efficient (memory wise) that a monolithic program that never frees memory until it exits.

Due to the pervasive influence of C, Unix is commonly thought of as a programming environment of manual memory management; you program Unix in C and C requires manual memory management.

That view is helped by the constant memory mismanagement in the UNIX clones.

It's just that we called this programming "shell scripts", "awk", "make", and so on.

Yes, and unlike a system that truly supports automatic memory management, each of those languages uses a different strategy, none of them operate with the other, and occasionally they have flaws that go unnoticed. The greater system operates unawares of their memory management, and so it's much less efficient.

In short, programming with automatic memory management has been a part of Unix from Bell Labs onward.

If so, why has it taken them decades to understand what real programmers knew in the 1950s, when garbage collection was created?

It's not some new intruder; it's a normal part of Unix, and the creators of Unix were clearly not philosophically opposed to automatic memory management under any circumstances.

Well, unless it's in UNIX itself, then it's bad and inefficient or whatever.

PS: Some of the automatic memory management is forced in various ways; for example, a declarative language like "make" doesn't really have room for manual memory management.

Yes; this is exactly how real researchers saw the need for it in the 1950s, with Lisp, a mere decade and some before make and the others.

To Orev, in that very artificial scenario, it's more efficient, sure; in general, it's not; in general, the UNIX sh model is insane in its inefficiency.

Written on 23 April 2023.
« The two types of C programmers (a provocative thesis)
Thinking about our passive exposure to IPv6 issues »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Apr 23 22:56:17 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.