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

31–40 of 64 posts

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

#31

Post by deliciousturkey »

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…

By that definition even C has garbage collection. Automatic storage duration types have compiler-determined lifetime and automatic deallocation.

If the definition of a word/concept does not match how the word is used in real life, the definition is wrong. After all, semantics is about common understanding of concepts. If your definition of a word doesn't match how it's used, using that definition is not beneficial to use.

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

#32

Post by gf000 »

deliciousturkey wrote: post #31
gf000 wrote: post #17

Earlier quoted context omitted.

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…

By that definition even C has garbage collection. Automatic storage duration types have compiler-determined lifetime and automatic deallocation. If the definition of a word/concept does not match how the word is used in real life, the definition is wrong. After all, semantics is about common understanding of concepts. If your definition of a word doesn't match how it's used, using that definition is not beneficial to…

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.

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

#33

Post by pron »

gdwatson wrote: post #23
gf000 wrote: post #17

Earlier quoted context omitted.

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…

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 is not necessarily the biggest of them.

For example, one of the most important distinctions in memory management is whether it optimises for footprint or speed (or some compromise), and the line isn't where people who don't understand memory management think it is. It can matter (often a great deal) whether you determine that an object is dead dynamically (say, by counting references) or statically (by manually writing free or by having the language track lifetimes), but it doesn't matter as much as whether or not the mechanism needs to know when objects are dead in the first place. So reference counting, manual free, static lifetimes, and even non-moving mark-and-sweep tracing collectors (like Go's) generally optimise for footprint at the expense of speed (although different allocators can have some control over that tradeoff), while arenas and tracing moving collectors optimise for speed at the expense of footprint (although here, too, they have some control over the tradeoff). So the line for this super-important tradeoff is between [manual, static, refcoutning] and [arenas, moving tracing]; non-moving tracing collectors are somewhere in between but may be closer to the first group.

People who don't understand memory management and may not have a lot of experience in low-level programming sometimes think that manual or statically-determined freeing must be fast because low-level languages, which inexperienced people think are fast, use them. In fact, low-level languages have some concerns that are much more important than speed and that preclude them from optimisations such as moving pointers. To get around that performance handicap, these languages try to avoid using their heap memory management as much as possible because they're using a rather slow technique because of their constraints.

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

#35

Post by deliciousturkey »

gf000 wrote: post #32
deliciousturkey wrote: post #31

Earlier quoted context omitted.

By that definition even C has garbage collection. Automatic storage duration types have compiler-determined lifetime and automatic deallocation. If the definition of a word/concept does not match how the word is used in real life, the definition is wrong. After all, semantics is about common understanding of concepts. If your definition of a word doesn't match how it's used, using that definition is not beneficial to…

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.

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

#36

Post by piinbinary »

I have this book and like it.

I also wish there was a book that guided you through the process of implementing a language with accurate garbage collection, similar to how Crafting Interpreters teaches you to implement a language. Perhaps it could start with a shadow stack + simple mark-and-sweep and then move on to stack maps + generational GC.

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

#37

Post by gf000 »

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.

Yeah, and?

We are in agreement here, C++ is not a GCd language. What I (we) claim is that reference counting is a GC, that's it. A language that uses RC 100% would be a GCd language, like python (okay, it does have a tracing GC to collect cycles as well). C++/rust has the necessary language primitives to express reference counting as a library, but that's an optional thing, usually applied only to select few objects. That's a bit like Java can also just allocate a byte buffer and do manual memory management, neither makes a language GCd/manual in and of itself.

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

#38

Post by LtdJorge »

PaulRobinson wrote: post #27
LandR wrote: post #26

Earlier quoted context omitted.

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

The physical copy will only get used by one reader (at a time). The ebook is going to be, err, "liberated" more often than not around a dorm? In all seriousness, this is likely a nudge to a preference they have for how they want to sell this and how you should want to buy it.

They advertise the ebook as having interactive features and more compared to the print version. Shouldn't it be the preferred one?

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

#39

Post by LtdJorge »

LandR wrote: post #26
Jtsummers wrote: post #12

Earlier quoted context omitted.

I thought I was missing something but figured they just didn't have a link to purchase it. I ended up going to the publisher's site to track it down: https://www.routledge.com/The-Garbage-Collection-Handbook-Th...

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.

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

#40

Post by dcuthbertson »

adrian_b wrote: post #18
rayiner wrote: post #5

How good are AIs at coding manual memory management? Is this a sea change in automatic memory management?

In my opinion, the "manual" memory management, introduced by the IBM PL/I programming language by the end of 1964, and inherited by C and other languages, i.e. where the programmer is responsible for invoking "free", was a serious mistake and it was an obsolete technique already at the date of its introduction. When the explicit "free" was invented, automatic memory reclamation while avoiding the non-determinism of g…

I too have written C programs for decades. I encountered reference counting when I learned how to write Windows kernel drivers. It was very liberating to see that there were so fewer opportunities for memory leaks when reference counts were applied liberally.
Post reply on HN