Do we need this book now that we have Rust ??
No. Rust has completely consigned all of computer science to the dustbin of irrelevance.
The Garbage Collection Handbook, 2nd Edition
111–120 of 174 posts
Re: The Garbage Collection Handbook, 2nd Edition
#112Re: The Garbage Collection Handbook, 2nd Edition
#113Earlier quoted context omitted.
Tracing is the worst in terms of performance
Anyone claiming something like this obviously hasn’t dig into GCs. You honestly think that writing into memory at each access, especially atomically is anywhere near the performance of a GC that can do most of its work in parallel and just flip a bit to basically “having deleted” everything no longer accessible?
a bit flip is not writing?
Also do traces not have to work atomically? The program needs to stop, you can’t have it check roots as it runs.
I’ll admit I am no GC researcher with ph.D experience, but your comment makes it seem you aren’t either.
Re: The Garbage Collection Handbook, 2nd Edition
#11420 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"!
Plot Twist:
20 years later, he wrote "The Garbage Collection Handbook" and is the leading authority on garbage collection.
Re: The Garbage Collection Handbook, 2nd Edition
#115Earlier 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)…
I've always heard of the "Swift elides reference counts" statements but I've never seen it substantiated. I don't claim to be a Swift GC expert by any means, but the impression I get from the two Swift GC papers I've read [1, 2] is that Swift has a very simple implementation of RC. The RC optimization document (albeit the document is incomplete) [3] also doesn't give me the impression that Swift is doing much eliding…
Swift's compiler elides obviously useless RC operations at compile time. It doesn't do anything at runtime though.
Re: The Garbage Collection Handbook, 2nd Edition
#116Earlier quoted context omitted.
Tracing is the worst in terms of performance
Not really, here it is winning hands down over Swift's ARC implementation. https://github.com/ixy-languages/ixy-languages
This isn't the kind of program Swift was designed to perform well for.
Nor is wallclock speed even what the system should be optimizing for, since you buy phones to run apps not to run the system. You should be measuring how well it gets out of the way of the important work.
Re: The Garbage Collection Handbook, 2nd Edition
#117Earlier quoted context omitted.
I've always heard of the "Swift elides reference counts" statements but I've never seen it substantiated. I don't claim to be a Swift GC expert by any means, but the impression I get from the two Swift GC papers I've read [1, 2] is that Swift has a very simple implementation of RC. The RC optimization document (albeit the document is incomplete) [3] also doesn't give me the impression that Swift is doing much eliding…
Swift's compiler elides obviously useless RC operations at compile time. It doesn't do anything at runtime though.
That is correct. Like Objective-C the compiler statically removes ARC when it can prove it doesn’t need it (or when you annotate it because where you’re getting it from is manually managing and giving you ownership of the reference). So within a function or cross function with LTO (although it looks like swift doesn’t yet have LTO [1] so I’m not sure about cross-module optimizations).
> When receiving a return result from such a function or method, ARC releases the value at the end of the full-expression it is contained within, subject to the usual optimizations for local values.
Quote from [2] (section 6 has the full details about optimizations). I believe [3] might be the compiler pass.
There actually is some elision that happens at runtime if you install an autoreleasepool if I recall correctly.
I did actually work at Apple so that’s where my recollection comes from although it’s been 8 years since then and I didn’t work on the compiler side of things so my memory could be faulty.
[1] https://github.com/apple/swift/pull/32233
[2] https://opensource.apple.com/source/lldb/lldb-112/llvm/tools...
Re: The Garbage Collection Handbook, 2nd Edition
#118Earlier quoted context omitted.
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 pointe…
Rust doesn’t use multi threaded Rc unless you actually need to send it across threads.
Re: The Garbage Collection Handbook, 2nd Edition
#119Earlier quoted context omitted.
Swift's compiler elides obviously useless RC operations at compile time. It doesn't do anything at runtime though.
That is correct. Like Objective-C the compiler statically removes ARC when it can prove it doesn’t need it (or when you annotate it because where you’re getting it from is manually managing and giving you ownership of the reference). So within a function or cross function with LTO (although it looks like swift doesn’t yet have LTO [1] so I’m not sure about cross-module optimizations). > When receiving a return result…
> So within a function or cross function with LTO (although it looks like swift doesn’t yet have LTO [1] so I’m not sure about cross-module optimizations).
I'm not sure Swift supports "static library modules" so in practice any linked object consists of a single module.
> There actually is some elision that happens at runtime if you install an autoreleasepool if I recall correctly.
There is a trick in the ObjC ABI that elides autorelease-returns, but it's deterministic after compilation time so I wouldn't call it a runtime optimization.
Re: The Garbage Collection Handbook, 2nd Edition
#120Earlier quoted context omitted.
Swift's compiler elides obviously useless RC operations at compile time. It doesn't do anything at runtime though.
That is correct. Like Objective-C the compiler statically removes ARC when it can prove it doesn’t need it (or when you annotate it because where you’re getting it from is manually managing and giving you ownership of the reference). So within a function or cross function with LTO (although it looks like swift doesn’t yet have LTO [1] so I’m not sure about cross-module optimizations). > When receiving a return result…
Thanks for the links!