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

61–70 of 174 posts

Re: The Garbage Collection Handbook, 2nd Edition

#61

Post by tomp »

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

Modern C++ has reference counting (“smart pointers”) and memory leaks instead, so YMMV.

Re: The Garbage Collection Handbook, 2nd Edition

#62

Post by vlovich123 »

admax88qqq wrote: post #54
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 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).

What papers are you referencing showing tracing GCs outperforming things? If it’s just the website, I think it’s an artifact of a micro benchmark rather than something that holds true for non trivial programs.

Re: The Garbage Collection Handbook, 2nd Edition

#63

Post by kenniskrag »

admax88qqq wrote: post #54
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 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.

How is that possible? Sounds counter-intuitive.

Do you have a recommendation for reading?

Re: The Garbage Collection Handbook, 2nd Edition

#67

Post by birdymcbird »

tomp wrote: post #61
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++:…

Modern C++ has reference counting (“smart pointers”) and memory leaks instead, so YMMV.

“And memory leaks instead” I choked on my morning coffee hahahahah

Re: The Garbage Collection Handbook, 2nd Edition

#68

Post by grumpy_coder »

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.

That is necessary but often not sufficient. It still leaves the problem of moving time from where garbage is created to the bulk 'collect' step. I've run collect every frame to keep stalls down, but the time always creeps up and up and you end up doing forensic analysis of which code is making the garbage in the first place.

Re: The Garbage Collection Handbook, 2nd Edition

#69

Post by kaba0 »

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

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.

Re: The Garbage Collection Handbook, 2nd Edition

#70

Post by kaba0 »

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?

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