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

91–100 of 174 posts

Re: The Garbage Collection Handbook, 2nd Edition

#91

Post by KerrAvon »

pjmlp wrote: post #75
vlovich123 wrote: post #62

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

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.

Re: The Garbage Collection Handbook, 2nd Edition

#93

Post by KerrAvon »

kaba0 wrote: post #69
vlovich123 wrote: post #62

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.

Because they don’t care as much about working set size as Apple does.

Re: The Garbage Collection Handbook, 2nd Edition

#94

Post by polynomial »

ajdude wrote: post #22
spapas82 wrote: post #5

20 years ago in the programming languages lesson at the university we started learning about OOP using Java and Ada as examples. When the professor started describing Java, a fellow student interrupted him to inform the class that "Java has garbage collection" (and boast of his special knowledge). After that incident his nickname was "the garbage collector"!

Coincidentally, Ada optionally supports garbage collection in its specifications but it's up to the runtime to implement it.

Ah, same as C++ it sounds like.

Re: The Garbage Collection Handbook, 2nd Edition

#95

Post by mcculley »

ajdude wrote: post #22
spapas82 wrote: post #5

20 years ago in the programming languages lesson at the university we started learning about OOP using Java and Ada as examples. When the professor started describing Java, a fellow student interrupted him to inform the class that "Java has garbage collection" (and boast of his special knowledge). After that incident his nickname was "the garbage collector"!

Coincidentally, Ada optionally supports garbage collection in its specifications but it's up to the runtime to implement it.

Which means no library can depend on it, pushing memory management responsibilities into calling code.

Re: The Garbage Collection Handbook, 2nd Edition

#96

Post by mcculley »

mananaysiempre wrote: post #12
LadyCailin wrote: post #10

Bizarre that you can't preorder it yet, you have to wait until June, just to preorder.

As a guess, they might want the accounting for preorders to fall into Q3? Is that a thing people do?

Maybe there is gamesmanship around best seller lists?

Re: The Garbage Collection Handbook, 2nd Edition

#97

Post by jlokier »

mananaysiempre wrote: post #36
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.

Bob Nystrom (of Game Programming Patterns , Crafting Interpreters , and dartfmt fame) also wrote a tutorial implementation[1], of a precise tracing GC as opposed to a conservative one. Regarding register scanning in a conservative GC, Andreas Kling has made (or at least quoted) the amusing observation[2] that your C runtime already has a primitive to dump all callee-save registers to memory: setjmp(). So all you have…

Glibc's mangles some pointer registers in setjmp(). It XORs a per-process value with the stack pointer, frame pointer and instruction pointer stored in the jmp_buf, on all (or nearly all) architectures.

Although losing the stack and instruction pointers is unlikely to be a problem for the GC context, the frame pointer register need not contain a frame pointer value. It can be an arbitrary program value depending on compile options. That's something to watch out for with this GC technique.

Re: The Garbage Collection Handbook, 2nd Edition

#98

Post by kaba0 »

KerrAvon wrote: post #93
kaba0 wrote: 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.

Because they don’t care as much about working set size as Apple does.

Sure, it is a tradeoff as basically every other technical choice.

But we were talking about performance here, and especially in throughput, tracing GCs are much better.

Re: The Garbage Collection Handbook, 2nd Edition

#99

Post by danappelxx »

saagarjha wrote: post #79
kaba0 wrote: post #70

Earlier quoted context omitted.

I don’t know anything about the benchmark, but how would you test GC implementations without reference types?

Swift’s value types have reference counts because they may have members that need their lifetimes to be managed appropriately. (For example, if they’re reference types.)

This is incorrect, value types are not referenced counted in Swift. If a value type contains a reference type member (usually an anti pattern!), then that member’s reference count is indeed incremented when the value type is copied. But it is not accurate to claim that value types themselves have reference counts.
Post reply on HN