Live data from Hacker News

The Garbage Collection Handbook, 2nd Edition

routledge.com

81–90 of 174 posts

Re: The Garbage Collection Handbook, 2nd Edition

#81

I feel the need for garbage collection is a language design mis-feature. That is to say, producing garbage is a language design-mis-feature. To quote Bjarne Stroustrup: > I don't like garbage. I don't like littering. My ideal is to eliminate the > need for a garbage collector by not producing any garbage. That is now > possible. and it's indeed possible. For example It's become pretty much a non-issue in modern C++:…

More and more people nowadays are programming at high levels of abstraction. If you're designing the frontend of a website, or making a mobile game, or developing a stock trading algorithm, or whatever else, then you probably don't want to constantly worry about details of memory management...

On top of this, GC is necessary for some algorithms. Any data structure with partial sharing (e.g. binary search tree with versioning via path-copying) needs GC to be space-efficient. You could either rely on a built-in GC, or write your own. If you write your own, I think you'll find that it is tedious and error-prone due to memory safety issues.

Re: The Garbage Collection Handbook, 2nd Edition

#82
post #11

Earlier quoted context omitted.

Who is Robert Sewell and why are his preferences interesting?

1. It’s a joke 2. Many great programmers hold the opinion that Java is horrible. Linus for example. So if Sewell doesn’t seem credible, try the creator of Linux and git.

I bet Linus does not get much outside C.

Re: The Garbage Collection Handbook, 2nd Edition

#83
post #80

Earlier quoted context omitted.

The goal was to write a network driver in several languages. Nobody said anything about comparing memory management techniques, nor would the Swift implementation use a stack allocator anyways.

They would appreciate your contribution to fix the benchmark. Apparently the ARC performance improvements announced at WWDC 2022 weren't needed.

I don’t think they would, considering they’ve already finished their study.

Re: The Garbage Collection Handbook, 2nd Edition

#86
post #69

Earlier quoted context omitted.

Tracing garbage collectors don’t generally win against reference counting connectors, especially when those reference counts are automatically elided via ARC (eg swift and objective C) or because they’re rarely used by means of composition (c++ and rust). Additionally, different kinds of application strategies are better depending on the use case (eg a pool allocator that you bulk drop at the end of some computation)…

Then why do every performant managed language opts for tracing GCs when they can? RC is used in lower level languages because it doesn’t require runtime support , and can be implemented as a library. As I wrote in another comment, even with elisions, you are still trading off constant writes on the working thread for parallel work, and you even have to pay for synchronization in parallel contexts.

this isn't fully true. Java is in the process of getting lxr which is uses both tracing and reference counting.

Re: The Garbage Collection Handbook, 2nd Edition

#88
post #11

Earlier quoted context omitted.

Who is Robert Sewell and why are his preferences interesting?

1. It’s a joke 2. Many great programmers hold the opinion that Java is horrible. Linus for example. So if Sewell doesn’t seem credible, try the creator of Linux and git.

> Many great programmers hold the opinion that Java is horrible.

Could you name a few?

Re: The Garbage Collection Handbook, 2nd Edition

#89
post #45

What I really want out of a garbage collector is a "Collect" function with a deadline. Pick a max time it's allowed to run before stopping and returning to the program.

Real time GCs exist such as the IBM Metronome GC. Though I'll be honest and say I haven't heard of many real-time GCs other than the Metronome one. Certainly many new GCs have reduced pause times dramatically but that's orthogonal to real-time GC (as you can make pause times infinitesimally small but not let the mutator actually progress).

Here’s a fairly extensive review that mentions some recent research on “real-time” GCs, including one with a lower bound for mutator utilization: https://eschew.wordpress.com/2016/09/02/summarizing-gc/.

Re: The Garbage Collection Handbook, 2nd Edition

#90
post #69

Earlier quoted context omitted.

Then why do every performant managed language opts for tracing GCs when they can? RC is used in lower level languages because it doesn’t require runtime support , and can be implemented as a library. As I wrote in another comment, even with elisions, you are still trading off constant writes on the working thread for parallel work, and you even have to pay for synchronization in parallel contexts.

this isn't fully true. Java is in the process of getting lxr which is uses both tracing and reference counting.

Yes and no. LXR is a highly optimized deferred and coalesced reference counting (amongst many other optimizations) GC and it looks nothing like the RC implementations you see in other languages like Python, Nim, Swift, etc. So yes, reference counting can be performant, _but_ only if you are using a deferred and coalesced implementation as otherwise the simple implementation requires atomic operations for every pointer read/write operation (though compilers could optimize it to use non-atomic operations when it's sure semantics are preserved).

EDIT: The post you're responding to is referring to the simple standard implementation of RC.

Post reply on HN