
Memory management in various languages (2014) - ingve
https://www.ravenbrook.com/project/mps/master/manual/html/mmref/lang.html
======
jhallenworld
I had not realized that this was all they did. I do remember the "Garbage
collecting" messages from the older versions.

"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."

~~~
lispm
CMUCL also used to inform the user about GCs. A mostly useless information.
MIT Lisp Machines had a visual indicator (a 'run bar' on the bottom of the
screen) of GC activity.

------
geocar
To my knowledge, most of these are pretty accurate, but there are some errors
that stand out to me:

* 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).

~~~
paxcoder
Recommend an essay that enumerates the techniques? Or if you don't know of
any, ping me when you write a blog post? :) Thanks in advance.

~~~
geocar
I might do that. In the meantime, Henry Baker's archive[1] contains lots of
techniques on garbage collection and heap compaction. I often recommend it.

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.

[1]:
[https://news.ycombinator.com/item?id=10871801](https://news.ycombinator.com/item?id=10871801)

[2]:
[http://www.brpreiss.com/books/opus5/html/page421.html](http://www.brpreiss.com/books/opus5/html/page421.html)

------
wilgertvelinga
What about PHP?

