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

21–30 of 64 posts

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

#21

Post by adrian_b »

a-french-anon wrote: post #19
rayiner wrote: post #5

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

GC's strength is not only in the ease of writing but at also reading, since you don't need to interleave allocation and business logic everywhere (be it through types or imperative code). GC simply is the only way to approach the clarity of pseudo-code in real code. That's one of my later realizations concerning the subject ( https://world-playground-deceit.net/blog/2024/11/how-i-learn... )

You mean "interleave deallocation and business logic everywhere".

For allocation there is no difference between automatic memory management with garbage collectors or reference counts and manual memory management, where the programmer is responsible for invoking "free".

These alternative memory management methods differ only in how deallocation is handled.

Allocation must always be done by defining a new object, regardless of how memory is managed. Moreover, allocation also does not depend on whether an object is allocated in static storage, in a stack or in a heap. You always must define the object, so that memory should be allocated for it at compile-time if in static storage, or at run-time if in a stack or in a heap.

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

#22

Post by hayley-patton »

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…

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

https://dl.acm.org/doi/10.1145/1035292.1028982

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

#23

Post by gdwatson »

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…

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 of garbage collection, because it is transparent to the programmer. Every memory management technique has tradeoffs and pathological edge cases, but since you don’t have to consider them in the ordinary course of programming I’d say it counts. If you had to break cycles manually, or to annotate which references should be counted, I’d call that refcounting but not GC – as in the C++ stdlib.

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

#24

Post by toolslive »

pdevr wrote: post #8

I had the 2012 print edition. One of the best books available - the best book that I knew - about GC at that time. Anti-pattern: Regarding the 2023 e-book edition, I do not see a way to buy it from the site, or even a link to buy.

I have the 2012 print edition too and fully concur with the assessment. The best book about garbage collection at the time (and maybe still?)

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

#25

Post by a-french-anon »

adrian_b wrote: post #21
a-french-anon wrote: post #19

Earlier quoted context omitted.

GC's strength is not only in the ease of writing but at also reading, since you don't need to interleave allocation and business logic everywhere (be it through types or imperative code). GC simply is the only way to approach the clarity of pseudo-code in real code. That's one of my later realizations concerning the subject ( https://world-playground-deceit.net/blog/2024/11/how-i-learn... )

You mean "interleave deallocation and business logic everywhere". For allocation there is no difference between automatic memory management with garbage collectors or reference counts and manual memory management, where the programmer is responsible for invoking "free". These alternative memory management methods differ only in how deallocation is handled. Allocation must always be done by defining a new object, rega…

Well, it's true that most of the noise comes from deallocation but I did mention types for good reasons: having your code littered with std::shared_ptr (or worse for Rust where encoding lifetime goes much further than Rc/Arc) is a direct consequence of wanting GC without a global one.

The source of my second revelation: GC should be opt-out (e.g. SBCL's arena system) instead of opt-in via refcounted types.

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

#26

Post by LandR »

Jtsummers wrote: post #12
pdevr wrote: post #8

I had the 2012 print edition. One of the best books available - the best book that I knew - about GC at that time. Anti-pattern: Regarding the 2023 e-book edition, I do not see a way to buy it from the site, or even a link to buy.

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!

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

#27

Post by PaulRobinson »

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!

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.

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

#28

Post by cb321 »

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 don't really disagree much with what you said. My favored PLang Nim (https://nim-lang.org/ -- it has both `ref` and `ptr` styles of pointer, one auto-managed, one manually managed) even changed a while back it's `nim c --gc=x` command-line language to `nim c --mm=x`, and I was in favor of said change.

However, it does inspire me to write.. The kernel of all this terminology confusion is under-exposure of industrial programmers to not just academic terminology, but also the very design space you mention (which has always been nicely covered by Jones' outstanding book). Just to take an example from the root of this thread:

>widespread common usage of the term “garbage collected programming language” which specifically contrasts manual languages like C++ or Rust against garbage collected ones

Boehm-Wiser conservative collection for C, among the most manual languages of all, pre-dates its very first ANSI 1989 standard.

This underexposure itself is downstream of the kinds of oversimplifications/lies of marketing and in this particular case came from Java. The evolution I witnessed was roughly 1) linking Boehm with -lgc and deleting (or #define'ing away) all your `free()` calls is conservative - to be precise you need compiler aid and a lot of programmers are "not perfect==awful" personality types, 2) Sun Microsystems wants to leverage a lot of reliability issues with C code and become The Platform and spends gobs of money to win hearts & minds, partly succeeding, 3) part of its ad-warfare against the then WIntel hegemony and/or tutorials/introductory material for Junior Programmers (often the target of "be more reliable" material) plays fast & loose with GC terminology because marketing plays fast & loose structurally for fun but mostly profit, 4) because human language really does == language usage a la Quine, everyone in the industry re-defines what "GC" means to bind it to a programming language instead of to a specific run-time, 5) industry & academics use different language, confusion ensues and so here we are.

This is not even the 100th time that either explicit or implicit forces of marketing have achieved confusion analogously to this. If you believe most people don't need much of what they spend on then confusion is arguably intrinsic to marketing of ideas/products. The highly misleading but suggestive metaphorical language used all over "AI" in both research and in product-lines is a more current case of this, leading anyone who knows much to have to qualify "not AGI" or other such junk just to have a conversation.

So, what is my point? Basically just that the larger problem here will persist as long as there is money to be made/attention to be garnered by sowing confusion/having people talk past each other/think some product is more than it really is. I have no meta-strategy in my back pocket to block these successful confusions, but it does seem worth being aware of it.

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

#29

Post by adrian_b »

a-french-anon wrote: post #25
adrian_b wrote: post #21

Earlier quoted context omitted.

You mean "interleave deallocation and business logic everywhere". For allocation there is no difference between automatic memory management with garbage collectors or reference counts and manual memory management, where the programmer is responsible for invoking "free". These alternative memory management methods differ only in how deallocation is handled. Allocation must always be done by defining a new object, rega…

Well, it's true that most of the noise comes from deallocation but I did mention types for good reasons: having your code littered with std::shared_ptr (or worse for Rust where encoding lifetime goes much further than Rc/Arc) is a direct consequence of wanting GC without a global one. The source of my second revelation: GC should be opt-out (e.g. SBCL's arena system) instead of opt-in via refcounted types.

While C and C++ have ugly syntaxes for "malloc", "std::shared_ptr" and the like, it is quite easy to mask that ugliness by using macros and writing thus only cleanly-looking programs, without any noise words and symbols around dynamic allocations.

In general, by using macros it is possible to transform so much a C or C++ program, that it becomes unrecognizable as C/C++ and it can mimic reasonably well any other programming language that you might fancy.

The problem is when you work in a team, because even if everyone will agree that such programming languages have great deficiencies, it would be impossible to reach a consensus about how the ideal programming language should look like, so eventually the team remains stuck with writing programs in the ugly standard manner.

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

#30

Post by pron »

gdwatson wrote: post #15
pron wrote: post #11

Earlier quoted context omitted.

> 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. This has been the standard terminology in memory management research for many decades. The only programmers who don't like it are those who don't understand the principles of memory…

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…

It's not about restricting the language. It's that practising programmers often don't know a subject well enough, so they use different words to make distinctions that don't matter as much as they think (see "transpile"). "Dynamically typed" is actually not that big of an offence (because the distinction is real, it's just that the terminology is a bit muddled), and the people in PL theory who are bothered by this (most notably one person) are considered pedants even among their colleagues.

E.g. many practising programmers don't know that tracing moving collectors are used to avoid some of the high overheads associated with memory allocators (malloc/free), which are themselves big and complex beasts that make up substantial "runtimes" (another misused and misleading word).

Post reply on HN