问题
Clarifying the question a bit:
Garbage collectors such as those used by the JVM involve a lot of complexity as a result of the nature of the languages they support. What simplifications would be afforded to a garbage collector purpose-built for a pure, functional, eagerly-evaluated programming language compared to say, the JVM garbage collector?
回答1:
I'm barely an expert in functional languages design but when thinking about your question, immediately the following topics come to my mind:
most probably it would be generational GC, at least I see no reason why it should not be. It could probably benefit from tuning to a large number of temporary objects
no write-barriers - due to immutability it is not possible to create a reference from older object to newer one. No older-to-younger references mean no need for the remembered sets in case of generational GC, thus no write-barriers are necessary to manage them. This is a great simplification in my humble opinion.
easier safe-points - due to the functional languages nature, function calls are much denser than in object-oriented programming. Even loops may be defined as recursive function calls. This should make implementing GC safe-points easier - for example, simply on each function entry. For example, read this article as a reference.
no pinning - if our hypothetical, pure functional language does not support native code cooperation, object pinning will not be necessary in case of compacting GC. This can greatly simplify its design.
no finalization - object finalization probably would not fit into purely functional language. I feel it breaks referential transparency. And if we do not support native resources, one will not need it at the first place.
来源：https://stackoverflow.com/questions/49561842/what-assumptions-could-a-garbage-collector-for-a-pure-functional-eagerly-evalu