Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

gchandbook.org

Post reply on HN
Print view View original

41–50 of 64 posts

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#41

Post by pron »

gf000 wrote: post #17
gdwatson wrote: post #15

Earlier quoted context omitted.

This reminds me a bit of the way academics in programming language theory internalized the type-theoretic definition of the word “type” over and against the traditional programming definition. You sometimes see people who try to correct the term “dynamically typed language,” which makes perfect sense when types are data types, to “untyped” or “unityped,” which makes sense when types are mathematical constructs equiva…

I think GC's definition is pretty clear cut. How is counting references to determine when a lifetime ends materially different from another way of doing the same thing? Like there is even a paper that shows that one is tracking liveness, while the other tracks "deadness" and they are literally going at the same thing from different ends. If anything, I often see a bias against tracing GCs from the people misusing the…

Right, and there are differences within tracing GCs that are just as big as between refcounting (and even manual malloc/free) and tracing. For example, Go uses tracing to determine when an object lifetime ends. But the moving collectors in Java, .NET, and V8 don't know and don't care when objects die, and they have no "free" operation at all. In many ways, the performance profile (of favouring smaller footprint or higher throughput) of memory management in C++, Rust, Python, and Go share more similarities among themselves than Java, .NET, V8, and Zig, which also share a more similar profile (arenas, like moving collectors, don't need or want to know when an object's lifetime ends).

Another distinction without a difference that is really just giving a name to a misconception is the notion of "a runtime". When I learnt C in the late 80s or early 90s, the book said something like, "C is not just the language, but a rich runtime". Indeed, modern malloc/free implementations mean that a C program ends up needing a larger and more elaborate runtime than a program in some educational language that uses a trivial implementation of a mark-and-sweep collector. Modern malloc/free allocators also sometimes come with an impressive set of tuning knobs. It's just that people who haven't had a lot of experience writing large programs in low-level languages don't know about them (or they just work to avoid allocations as much as possible, because that's what they've been told to do).

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#42

Post by kibwen »

hamstergene wrote: post #6

What I didn’t like about this series of books was choosing “garbage collection” as umbrella term for both tracing GC and reference counting, without verifying if programming community would agree with that, which turned out they didn’t. I’ve seen a lot of threads here and on reddit where people were arguing about terminology purely because of this book alone. By that definition, C++ code has garbage collection if it…

Instead of "garbage collection", you can say "dynamic lifetime determination". If code does work at runtime to answer the question "is it safe to free this piece of memory?", that's dynamic lifetime determination, and is a property shared by both reference-counting and more sophisticated GC schemes.

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#43

Post by pmarreck »

LtdJorge wrote: post #39
LandR wrote: post #26

Earlier quoted context omitted.

How on earth is the ebook more expensive than the physical copy!

And it's not an actual ebook. You have to create an account on the "ebook" provider's site and read it through their website or app.

I hate when they do this. I'd rather just buy the physical book, donate it to a library and then obtain the liberated version of the ebook "elsewhere".

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#45

Post by metalliqaz »

LtdJorge wrote: post #39
LandR wrote: post #26

Earlier quoted context omitted.

How on earth is the ebook more expensive than the physical copy!

And it's not an actual ebook. You have to create an account on the "ebook" provider's site and read it through their website or app.

Worthless.

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#46

Post by pron »

deliciousturkey wrote: post #35
gf000 wrote: post #32

Earlier quoted context omitted.

Well yeah, stack variables are automatically reclaimed. What's your issue? It's just that this is not the predominant way C programs are written and for everything else you do need to somehow manage the memory, malloced objects would otherwise just leak. What exactly is the issue, the real life use of C requires manually adding free calls, is it not? So it doesn't do automatic memory management for you.

The term "garbage collection" does not mean that the language has some mechanism of automatically reclaiming some memory. If it did, C would be a garbage-collected language. The term is not used in such way. Now, of course reference counting can be used as a part of a garbage collector. But that doesn't mean any language that allows you to implement reference counting as a library, is a garbage-collected language.

> But that doesn't mean any language that allows you to implement reference counting as a library, is a garbage-collected language.

The concept of "a garbage-collected language" is not well-defined. There are languages, like Java, Rust, and Python that depend on a garbage collection mechanism, and languages like C, C++ and Zig, which don't. C++ happens to offer a GC in its standard library, however.

That "working developers" use some other terminology is not what matters. What matters is whether the terminology they're using expresses important distinctions or not (and may, in fact, express misconceptions about distinctions). In the case of memory management (as in the case of "transpiles", although there the damage isn't as high), the colloquial terminology is misleading as it is used to hint at distinctions (such as about performance) which are simply not there. E.g. moving GCs are used to avoid the performance overheads of malloc/free, especially in large and/or concurrent programs. This performance overhead that C and C++ suffer from is well known to experienced low-level developers (which is partly why large programs that benefit from moving collectors are relatively rarely written in such languages anymore), but now the terminology is used as a cargo cult, which leads to conclusions that are sometimes the very opposite of what's really going on.

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#47

Post by mschuetz »

hamstergene wrote: post #6

What I didn’t like about this series of books was choosing “garbage collection” as umbrella term for both tracing GC and reference counting, without verifying if programming community would agree with that, which turned out they didn’t. I’ve seen a lot of threads here and on reddit where people were arguing about terminology purely because of this book alone. By that definition, C++ code has garbage collection if it…

I've always considered shared_ptr to be semi-garbage collection. Allows me to code C++ almost as if it were Java so long as circular references are avoided. I'm perfectly fine with it being considered a type of garbage collection.

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#48

Post by Jtsummers »

mschuetz wrote: post #47
hamstergene wrote: post #6

What I didn’t like about this series of books was choosing “garbage collection” as umbrella term for both tracing GC and reference counting, without verifying if programming community would agree with that, which turned out they didn’t. I’ve seen a lot of threads here and on reddit where people were arguing about terminology purely because of this book alone. By that definition, C++ code has garbage collection if it…

I've always considered shared_ptr to be semi-garbage collection. Allows me to code C++ almost as if it were Java so long as circular references are avoided. I'm perfectly fine with it being considered a type of garbage collection.

> so long as circular references are avoided

And there's always weak_ptr if a cycle makes sense for some reason but you still want it to clean up correctly. Like having a child node point up to a parent or the root in a tree structure.

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#49

Post by senderista »

pron wrote: post #46
deliciousturkey wrote: post #35

Earlier quoted context omitted.

The term "garbage collection" does not mean that the language has some mechanism of automatically reclaiming some memory. If it did, C would be a garbage-collected language. The term is not used in such way. Now, of course reference counting can be used as a part of a garbage collector. But that doesn't mean any language that allows you to implement reference counting as a library, is a garbage-collected language.

> But that doesn't mean any language that allows you to implement reference counting as a library, is a garbage-collected language. The concept of "a garbage-collected language" is not well-defined. There are languages, like Java, Rust, and Python that depend on a garbage collection mechanism, and languages like C, C++ and Zig, which don't. C++ happens to offer a GC in its standard library, however. That "working dev…

I think it would be a salutary experience for every C/C++ programmer to write a decently-performing allocator so they could appreciate the complexity and overhead required to avoid excessive fragmentation (especially in long-running programs with long-lived allocations and irregular deallocations), given the constraint of address stability.

Re: The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) (2023)

#50

Post by senderista »

pron wrote: post #33
gdwatson wrote: post #23

Earlier quoted context omitted.

I think a lot of people just want to be able to discuss different areas of the automatic memory management design space separately, and maintaining the distinction between reference counting and garbage collection (meaning tracing GCs) lets them do that. As for me personally, I consider refcounting and GC overlapping categories. I am perfectly willing to call CPython’s reference counting plus cycle collector a form o…

> I think a lot of people just want to be able to discuss different areas of the automatic memory management design space separately, and maintaining the distinction between reference counting and garbage collection (meaning tracing GCs) lets them do that. The problem is that there are many differences in memory management techniques that offer different tradeoffs, and the difference between refcounting and tracing i…

"Speed" is also ambiguous between latency and throughput. You seem to be using "speed" here as a synonym for throughput. Because of Little's Law, the memory consumed by deallocated objects is directly proportional to deallocation latency, so "low footprint" also generally means "low latency", while increasing throughput by amortizing deallocation overhead at the expense of latency increases memory usage for the same reason.
Post reply on HN