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

51–60 of 174 posts

Re: The Garbage Collection Handbook, 2nd Edition

#51

Post by sirwhinesalot »

rwmj wrote: post #46
sirwhinesalot wrote: post #39

Earlier quoted context omitted.

The increment/decrement calls only occur on an explicit call to .clone(). No .clone(), no increment/decrement. You won't see many clones in rust code.

It's how often reference counts are adjusted on hot paths that matters (including in libraries), and back to the original point, reference counting doesn't let you free groups of objects in one go (unlike a tracing GC). Also it'd be nice if the reference counts were stored separately from the objects. Storing them alongside the object being tracked is a classic mistake made by reference count implementations (it spre…

The amount of reference-counted pointers in most Rust code is a tiny fraction compared to boxes or compiler-tracked-lifetime references.

Yes in theory it would be more efficient to store all the reference counts together, but that's in theory. In practice most Rust apps will not call clone on a shared pointer on a hot path and if they do it's usually 1 such pointer and they do something with the data as well (so it's all 1 cache line anyway)

You can't compare Rust/C++ with Swift/Nim when it comes to RC, there just aren't enough reference count operations for it to matter much (unless you're in a shitty OO C++ codebase like me that pretends it is java with std::shared_ptr everywhere)

Apps where heap compaction would be relevant in a low-level language like Rust or C++ will typically use a bump allocator which will trounce any kind of GC.

Re: The Garbage Collection Handbook, 2nd Edition

#52

Post by saagarjha »

sirwhinesalot wrote: post #38
mananaysiempre wrote: post #36

Earlier quoted context omitted.

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…

Implementations are unfortunately allowed to do whatever they want to that jmp_buf, they could xor the contents for all you know. Hopefully no implementation does something silly like that.

Seems like a reasonable thing to do to avoid forging jmp_bufs.

Re: The Garbage Collection Handbook, 2nd Edition

#53

Post by saagarjha »

mr_00ff00 wrote: post #20
frou_dh wrote: post #11

Earlier quoted context omitted.

Who is Robert Sewell and why are his preferences interesting?

1. It’s a joke 2. Many great programmers hold the opinion that Java is horrible. Linus for example. So if Sewell doesn’t seem credible, try the creator of Linux and git.

Linus's thoughts on programming languages aren't particularly enlightening either ;)

Re: The Garbage Collection Handbook, 2nd Edition

#54

Post by admax88qqq »

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

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.

Re: The Garbage Collection Handbook, 2nd Edition

#55

Post by saagarjha »

pjmlp wrote: post #29
mr_00ff00 wrote: post #19

Earlier 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

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

Re: The Garbage Collection Handbook, 2nd Edition

#56

Post by einpoklum »

sirwhinesalot wrote: post #48
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++:…

C++ can actually produce quite a bit of garbage unintentionally, it's why linters will remind you often to call std::move. That said I much prefer deterministic resource cleanup even in a janky language like C++ over a tracing GC.

It's true that C++ can trigger a lot of unnecessary copying if one writes carelessly; but that's not the same as garbage, in that both copies are used, and none of them continue living indefinitely without special intervention. But point taken about pass-by-value deficiencies.

Re: The Garbage Collection Handbook, 2nd Edition

#57

Post by auxym »

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.

Nim has exactly that with the GC_step proc.

https://nim-lang.org/1.4.0/gc.html

However recent and future versions (2.0) are moving towards a different approach that is also applicable for deterministic real time systems: ARC, which is basically alloc and free calls inserted automatically by the compiler using static analysis (no "runtime").

Re: The Garbage Collection Handbook, 2nd Edition

#58

Post by einpoklum »

winrid wrote: post #37
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++:…

I wouldn't say it's a non issue. I frequently have to tune allocators to fix heap fragmentation in databases...

Recognized on the last line of the post I linked to actually.

Re: The Garbage Collection Handbook, 2nd Edition

#59

Post by lispm »

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

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

Re: The Garbage Collection Handbook, 2nd Edition

#60

Post by [deleted] »

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

[deleted]
Post reply on HN