Friendship ended with the garbage collector

Re:Friendship ended with the garbage collector by pjc50 on Friday August 27, 2021 @04:43AM (#28325595)

The traditional alternative is what I might call "static reference counting", where the programmer knows by inspection/convention (C) or through the type system (Rust) how many references exist at any point statically, so they can skip the dynamic reference count entirely.

I agree that malloc/new is comparatively expensive, but that ends up as a cost borne by all heap-allocated variables in every language. Unless people use special techniques like pool or slab allocators.

[ Parent | on HN ]

Re:Friendship ended with the garbage collector by loup-vaillant on Friday August 27, 2021 @05:19AM (#28325754)

There's a huge difference between C/C++'s malloc() and a precise garbage collector: with the former all objects are fixed. With the latter you can move them around. This means malloc() is more constrained than a GC, and that makes it slower.

The real gains of managing memory manually is not in the speed of malloc(), but in the fact that in practice you can perform far fewer heap allocations.

[ Parent | on HN ]

Re:Friendship ended with the garbage collector by zozbot234 on Friday August 27, 2021 @04:58AM (#28325653)

Rust also allows for non-thread safe reference-counted objects (Rc<>) that don't have the overhead of atomic instructions for updating the reference count. And it's getting support for custom local allocators, addressing the overhead of malloc/free. Along with a bunch of further advantages compared to C++ shared_ptr (such as being able to dispense with a pointer indirection in some cases, and allowing for sub-borrows that don't even need a refcount update because they can't possibly affect the 'ownership' of the object).

[ Parent | on HN ]