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

71–80 of 174 posts

Re: The Garbage Collection Handbook, 2nd Edition

#71

Post by kaba0 »

einpoklum wrote: post #33

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++:…

You can’t avoid garbage if you deal with generic programs — Rust and C++ can only implement a subset of all programs without RC (which is the most basic GC algorithm).

This is the same way to many other interesting CS properties — most of them are undecidable at compile time, so you have to do it at runtime.

Re: The Garbage Collection Handbook, 2nd Edition

#72

Post by NobleExpress »

vlovich123 wrote: post #62
admax88qqq wrote: post #54

Earlier quoted context omitted.

There was this project though. https://github.com/Roldak/AGC The best part is that it's faster than manual management. People will tell you they need do to malloc and free manually for performance, but when you actually run the numbers GC wins for a majority of use cases.

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 of reference counts (I'm sure it is doing it for simple cases).

Do you have any links which might explain what kind of eliding Swift is doing?

EDIT: The major RC optimizations I have seen which elide references are deferral and coalescing and I'm fairly certain that Swift is doing neither.

[1]: https://dl.acm.org/doi/abs/10.1145/3170472.3133843

[2]: https://doi.org/10.1145/3243176.3243195

[3]: https://github.com/apple/swift/blob/main/docs/ARCOptimizatio...

Re: The Garbage Collection Handbook, 2nd Edition

#73

Post by pjmlp »

saagarjha wrote: post #55
pjmlp wrote: post #29

Earlier quoted context omitted.

Not really, here it is winning hands down over Swift's ARC implementation. https://github.com/ixy-languages/ixy-languages

Wasn't this the comparison that decided to use reference types for everything for no real reason?

The reason being comparing how various schemes of automatic reference memory management perform.

Naturally if the purpose was to compare stack allocation performance other approach would have been taken.

Re: The Garbage Collection Handbook, 2nd Edition

#74

Post by syngrog66 »

pjmlp wrote: post #27
ajdude wrote: post #22

Earlier quoted context omitted.

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

And since no implementation has ever supported it, it has been deprecated in ISO Ada 95 and further removed from it on ISO Ada 2012. https://en.wikibooks.org/wiki/Ada_Programming/Pragmas/Contro...

> and further removed from it on ISO Ada 2012.

and in that precise moment Ada proved it had garbage collection all along

Re: The Garbage Collection Handbook, 2nd Edition

#75

Post by pjmlp »

vlovich123 wrote: post #62
admax88qqq wrote: post #54

Earlier quoted context omitted.

There was this project though. https://github.com/Roldak/AGC The best part is that it's faster than manual management. People will tell you they need do to malloc and free manually for performance, but when you actually run the numbers GC wins for a majority of use cases.

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.

Re: The Garbage Collection Handbook, 2nd Edition

#76

Post by pjmlp »

lispm wrote: post #59
pjmlp wrote: post #27

Earlier quoted context omitted.

And since no implementation has ever supported it, it has been deprecated in ISO Ada 95 and further removed from it on ISO Ada 2012. https://en.wikibooks.org/wiki/Ada_Programming/Pragmas/Contro...

There was an Ada implementation on the Lisp Machine, that might have been using GC.

As for .NET and JVM implementations, but that is a consequence of underlying platform, just like C++/CLI and C++/CX, and none of them have been that big into the Ada compiler market.

Re: The Garbage Collection Handbook, 2nd Edition

#77

Post by saagarjha »

pjmlp wrote: post #73
saagarjha wrote: post #55

Earlier quoted context omitted.

Wasn't this the comparison that decided to use reference types for everything for no real reason?

The reason being comparing how various schemes of automatic reference memory management perform. Naturally if the purpose was to compare stack allocation performance other approach would have been taken.

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.

Re: The Garbage Collection Handbook, 2nd Edition

#78

Post by pjmlp »

NobleExpress wrote: post #49
Dwedit wrote: 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).

See PTC and Aicas.

Re: The Garbage Collection Handbook, 2nd Edition

#79

Post by saagarjha »

kaba0 wrote: post #70
saagarjha wrote: post #55

Earlier quoted context omitted.

Wasn't this the comparison that decided to use reference types for everything for no real reason?

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

Re: The Garbage Collection Handbook, 2nd Edition

#80

Post by pjmlp »

saagarjha wrote: post #77
pjmlp wrote: post #73

Earlier quoted context omitted.

The reason being comparing how various schemes of automatic reference memory management perform. Naturally if the purpose was to compare stack allocation performance other approach would have been taken.

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.

Post reply on HN