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

The Garbage Collection Handbook, 2nd Edition

routledge.com

Post reply on HN
Print view View original

151–160 of 174 posts

Re: The Garbage Collection Handbook, 2nd Edition

#151

Post by culi »

juunpp wrote: post #41
samsquire wrote: post #28

if you need code to understand garbage collection, there is walkthrough of garbage collector and C code at http://maplant.com/gc.html is really helpful. I tweaked it to work on amd64 and started adding register scanning based on what eatonphil's discord people told me to do. https://github.com/samsquire/garbage-collector It's not fit for any purpose but more of a learning exercise.

Side topic, but the maplant website design is great.

Besides the code blocks, it has 0 CSS. So what you're actually complementing is your browser's default styles for HTML

Re: The Garbage Collection Handbook, 2nd Edition

#152

Post by microtherion »

vincent-manis wrote: post #87
mkl95 wrote: post #40

Will there be a PDF / epub option?

If I'm not mistaken, Routledge uses that VitalSource dreck, so you can only read their ebooks via a dedicated app. I don't buy dead-tree books any more, but I'll make an exception for this one.

The previous edition of this book is available on e.g. Apple's bookstore and Kindle. Unfortunately, the new one does not show an eBook option yet. I very much hope that one will be available soon, instead of them holding back the eBook to goose hardcover sales or some other reason.

Re: The Garbage Collection Handbook, 2nd Edition

#153

Post by sirwhinesalot »

jimsimmons wrote: post #150
sirwhinesalot wrote: post #103

I don't know if it is included in the new edition of the book but in case anyone is interested in a modern, highly efficient RC implementation that does not rely on deferring the reference count updates (which kills one of the advantages of RC in the first place), check the Perseus paper. Koka (which uses perseus) is quite competitive with OCaml and Haskell Just search for "perseus reference counting", you'll find it…

Apart from the paper are there independent verifications of the technique's performance?

The Roc language uses it too and shows similar performance. It's not magic though, it just takes advantage of RC for various optimizations (like "Functional But In Place") which add up and compensate for the added burden of ref count manipulation.

Re: The Garbage Collection Handbook, 2nd Edition

#156

Post by astrange »

pjmlp wrote: post #143
vlovich123 wrote: post #124

Earlier quoted context omitted.

Because tracing GCs can solve referential loops which RC can’t. So at the language level where you have to handle all sorts of programs written by programmers of varying quality (+ mistakes) a tracing GC gives better predictable memory usage performance across a broader range of programs. Seriously. A single threaded reference counter is super cheap. Cross thread reference counts shouldn’t be used and I think are an…

So fast that Apple Silicon introduced specific memory instructions to handle ARC counters.

It did not do this, standard atomics are relatively fast because it's a unified memory system.

Re: The Garbage Collection Handbook, 2nd Edition

#157

Post by astrange »

KerrAvon wrote: post #91
pjmlp wrote: post #75

Earlier quoted context omitted.

Swift and Objective-C ARC performance is quite poor.

Compared to what, though? And is that still the case if all OS components use whatever it is, as opposed to a few applications? Memory efficiency is crucial for overall system performance, and ARC is highly memory-efficient compared to every production GC I’m aware of.

Peak memory is not the only reason ARC is memory-efficient though, the main reason is that it has better memory reading behavior because it doesn't have to scan for pointers. Server GCs assume all memory containing pointers is cheap to access, which is not true if some of it is swapped out.

Re: The Garbage Collection Handbook, 2nd Edition

#159

Post by _a_a_a_ »

kaba0 wrote: post #142
vlovich123 wrote: post #124

Earlier quoted context omitted.

Because tracing GCs can solve referential loops which RC can’t. So at the language level where you have to handle all sorts of programs written by programmers of varying quality (+ mistakes) a tracing GC gives better predictable memory usage performance across a broader range of programs. Seriously. A single threaded reference counter is super cheap. Cross thread reference counts shouldn’t be used and I think are an…

Obviously the 3 objects you allocate with shared_ptr in C++ won’t be a performance bottleneck, but then we are not comparing apples to oranges. Your single threaded RC will still have to write back to memory, no one thinks that incrementing an integer is the slow part — destroying cache is.

> Your single threaded RC will still have to write back to memory

I think you mean mem or cache, and there's a good chance it will remain in cache and not be flushed to ram for short lived objects.

> no one thinks that incrementing an integer is the slow part — destroying cache is.

agreed

Re: The Garbage Collection Handbook, 2nd Edition

#160

Post by kaba0 »

_a_a_a_ wrote: post #159
kaba0 wrote: post #142

Earlier quoted context omitted.

Obviously the 3 objects you allocate with shared_ptr in C++ won’t be a performance bottleneck, but then we are not comparing apples to oranges. Your single threaded RC will still have to write back to memory, no one thinks that incrementing an integer is the slow part — destroying cache is.

> Your single threaded RC will still have to write back to memory I think you mean mem or cache, and there's a good chance it will remain in cache and not be flushed to ram for short lived objects. > no one thinks that incrementing an integer is the slow part — destroying cache is. agreed

If you write to cache, then depending on architecture that change has to be made visible to every other thread as well. Reading is not subject to such a constraint.
Post reply on HN