Live data from Hacker News

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

gchandbook.org

51–60 of 64 posts

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

#51
post #33

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

> so "low footprint" also generally means "low latency"

Not anymore.

You're absolutely right that one of the reasons moving collectors were not used more widely was that, while their throughput was always very impressive, their latency wasn't that great, but that changed a few years ago.

E.g. Generational ZGC in OpenJDK (released in September '23) introduces hiccups or "pauses" that are not dependent on the size of the liveset and are no larger than latency hiccups introduced by the OS (assuming no realtime kernel), i.e. So modern moving GCs no longer have a latency penalty, but this is newer than even ChatGPT.

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

#52

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…

The Linux kernel has garbage collection, and not just the controversial refcount kind.

I'll go further. Linux heavily uses a form of garbage collection that cannot be implemented in typical userspace (without awkward & slower additions to the consistency algorithm).

https://en.wikipedia.org/wiki/Read-copy-update

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

#53
post #32

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.

Gilad Bracha wrote a fascinating piece on how tail call optimization could be implemented with periodic collection instead of immediately reusing the call frame, it's a fascinating piece: https://gbracha.blogspot.com/2009/12/chased-by-ones-own-tail...

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

#54
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…

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

It wasn’t obsolete then nor now. Garbage collected languages, to this day, still use on average about 2x-5x the working memory of carefully written manual memory programs. A significant amount of devices then and even today cannot support such sloppy use of resources.

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

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

Yuck. I'd never buy that, no matter how much I wanted to read the content.

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

#56
post #51

Earlier quoted context omitted.

"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…

> so "low footprint" also generally means "low latency" Not anymore. You're absolutely right that one of the reasons moving collectors were not used more widely was that, while their throughput was always very impressive, their latency wasn't that great, but that changed a few years ago. E.g. Generational ZGC in OpenJDK (released in September '23) introduces hiccups or "pauses" that are not dependent on the size of t…

Where could one find resources about implementing such GCs in their own language?

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

#57
post #51

Earlier quoted context omitted.

> so "low footprint" also generally means "low latency" Not anymore. You're absolutely right that one of the reasons moving collectors were not used more widely was that, while their throughput was always very impressive, their latency wasn't that great, but that changed a few years ago. E.g. Generational ZGC in OpenJDK (released in September '23) introduces hiccups or "pauses" that are not dependent on the size of t…

Where could one find resources about implementing such GCs in their own language?

https://www.taylorfrancis.com/books/mono/10.1201/97810035953...

Note that this is a pretty new technology. The first production-quality "pauseless" moving collector for commodity hardware was released in 2010 by Azul, but it was proprietary. The first open source implementation (that was also generational) was in JDK 21 (https://openjdk.org/jeps/439), i.e. it's less than three years old. The book I linked to is by one of the primary designers of that GC (and one of the world's foremost experts on memory management).

ZGC does no work in stop-the-world pauses; no marking, no compacting, not even root scanning.

Of course, if your language targets the JVM, it will automatically get to enjoy that amazing GC.

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

#59
post #46

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…

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

How does Rust differ from C++ in this regard?

As far as I know, both use RAII, and offer something RC-like in their stdlib that is optional to use.

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

#60

Earlier quoted context omitted.

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…

> 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. It wasn’t obsolete then nor now. Garbage collected languages, to this day, still use on average about 2x-5x the working memory of carefully written manual memory programs. A significant amount of devices then and even today cannot support such sloppy use of resourc…

I think they mean something more akin to RAII in C++/rust. Manually writing a free statement is very error-prone and there are better language-level features to avoid that.
Post reply on HN