Memory management in various languages (2014)
ravenbrook.com
ravenbrook.com
"Like most Lisps, Emacs Lisp requires garbage collection. GNU Emacs has a simple mark-sweep collector. It has been speculated that the non-incremental nature of the Emacs collector, combined with the fact that, prior to version 19.31 (May 1996), it printed a message whenever it collected, gave garbage collection a bad name in programming circles.
Erik Naggum reported at the time:
I have run some tests at the U of Oslo with about 100 users who generally agreed that Emacs had become faster in the latest Emacs pretest. All I had done was to remove the “Garbage collecting” message which people perceive as slowing Emacs down and tell them that it had been sped up. It is, somehow, permissible for a program to take a lot of time doing any other task than administrative duties like garbage collection."
* BASIC string handling does not require garbage collection (in the sense used by all the other languages) because there's no aliasing. What many BASIC implementations referred to as garbage collection was to my knowledge simply heap compaction.
* COBOL programmers do not normally use ALLOCATE and FREE, but instead map records directly with READ ... KEY and WRITE.
* Common-Lisp as a specification doesn't require garbage collection. Lisp doesn't require garbage collection. See for example Baker's Linear Lisp. While most lisps are garbage-collected, Python (for example) differentiates different "dialects" of python so I would think it makes sense to do it here.
* Java has many implementations, some of which allows garbage collection to be disabled.
* Perl also supports a "last ditched effort" buffer which can be used to recover from out of memory errors ($^M) which is useful.
* Smalltalk uses the term "automatic memory management" which I think can include reference counting, but Smalltalk doesn't (easily) support reference counting. It should say garbage collection. Garbage Collection may be Automatic Memory Management, but Automatic Memory Management isn't (necessarily) Garbage Collection.
Another issue I have is that C uses its space for editorialising, and this seems wrong.
Those errors are possible any time the programmer manages memory directly, and are easy to avoid with a number of simple techniques. It is in fact the "standard memory management" (malloc/free) and single-heap core that is horrible and (in my opinion) most contributory to those bugs. More opinion: the worst part about C is the self-hating and reluctant C programmers (followed shortly by the ones that don't program in C anymore).
It doesn't mention it. Practically GC is required and almost all implementations provide one or more versions of garbage collection. Additionally there are small language subsets with manual memory management.
There are/were some Lisps with reference-counting-like memory management.
Reference counting can fit on a page[2]. Even though Perl uses it where it's a bad fit, Q/KDB use it and it's a great fit: Because arrays are very big, being able to optimise on count=1 and reuse the buffer is a valuable optimisation!
Something that I think would be useful would be an examination of the performance characteristics of different techniques (especially considering new superscalar chips and hardware transactional memory), but this would take some time.