4 ms·

For a unifying term I prefer Automatic Memory Management. One reason is that GC is already universally used to mean only tracing garbage collection, and trying

For a unifying term I prefer Automatic Memory Management. One reason is that GC is already universally used to mean only tracing garbage collection, and trying to defend its wider meaning is a pointless uphill battle. Another is that is suits the job much better, because not every AMM technique works by producing garbage then collecting it, you know.

omginternets 4y ago
What are these other techniques and what can a technically-literate newcomer like myself read to get acquainted?
kibwen 4y ago
If you want to get even more precise, call it automatic dynamic memory management. Automatic static memory management would be something like Rust's scope-based memory reclamation via ownership.
- pjmlp 4y ago
  Great to confuse more people instead of properly learning about affine type systems.
  - kibwen 4y ago
    There's no confusion here? This is a perfectly natural classification, that satisfies many people's intuition about Rust as having "compile-time GC". If anything, bringing up affine type systems is more liable to confuse people in this context; just because a language has an affine type system doesn't necessarily mean it needs to use it for memory management.
pjmlp 4y ago
I just keep feeding them the respective CS literature.
Someone 4y ago
> not every AMM technique works by producing garbage then collecting it And the confusing thing is that garbage collection (GC) doesn’t collect garbage, while reference counting (RC) does. GC doesn’t look at every object to decide whether it’s garbage (how would it determine nothing points at it?); it collects the live objects, then discards all the non-live objects as garbage. RC determines an object has become garbage when its reference count goes to zero, and then collects it. That difference also is one way GC can be better than RC: if there are L live objects and G garbage objects, GC has to visit L objects, and RC G. Even if GC spends more time per object visited than RC, it still can come out faster if L ≪ G. That also means that GC gets faster if you give it more memory so that it runs with a smaller L/G ratio (the large difference in speed in modern memory cache hierarchies makes that not quite true, but I think it still holds, ballpark)

omginternets 4y ago

What are these other techniques and what can a technically-literate newcomer like myself read to get acquainted?

kibwen 4y ago

If you want to get even more precise, call it automatic dynamic memory management. Automatic static memory management would be something like Rust's scope-based memory reclamation via ownership.

pjmlp 4y ago
Great to confuse more people instead of properly learning about affine type systems.
- kibwen 4y ago
  There's no confusion here? This is a perfectly natural classification, that satisfies many people's intuition about Rust as having "compile-time GC". If anything, bringing up affine type systems is more liable to confuse people in this context; just because a language has an affine type system doesn't necessarily mean it needs to use it for memory management.

pjmlp 4y ago

I just keep feeding them the respective CS literature.

Someone 4y ago

> not every AMM technique works by producing garbage then collecting it And the confusing thing is that garbage collection (GC) doesn’t collect garbage, while reference counting (RC) does. GC doesn’t look at every object to decide whether it’s garbage (how would it determine nothing points at it?); it collects the live objects, then discards all the non-live objects as garbage. RC determines an object has become garbage when its reference count goes to zero, and then collects it. That difference also is one way GC can be better than RC: if there are L live objects and G garbage objects, GC has to visit L objects, and RC G. Even if GC spends more time per object visited than RC, it still can come out faster if L ≪ G. That also means that GC gets faster if you give it more memory so that it runs with a smaller L/G ratio (the large difference in speed in modern memory cache hierarchies makes that not quite true, but I think it still holds, ballpark)