Hacker News Reader

Comment by jgaa | Hacker News Reader

The first question I asked myself when I read the topic-line was: "Why would I want a garbage collector for C++"

I'm not saying that it's a bad idea. I'm just curious about why/when garbage collection is better than conventional use of unique_ptr or shared_ptr.

View on HN

In early attempts of removing GIL, atomic reference counting slows down performance by 60%. In comparison, tracing garbage collector can defer/coalesce reference counting. You can read more in [2] section 2.1, and this paper introduced a new referencing counting method.

[1] Multithreaded Python without the GIL https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... [2] Low-Latency, High-Throughput Garbage Collection https://users.cecs.anu.edu.au/~steveb/pubs/papers/lxr-pldi-2...

Makes writing lock free data structures a heck of a lot easier. Entirely eliminates the ABA problem.

Unreal C++ and C++/CLI have one.

When one wants the flexibility of C++ with the productivity of a GC.

Whether GC improves productivity is a strong claim that needs a proof. I have yet to see such a proof.

So far my experience has been that (nondeterministic) GC is only a productivity improvement over languages with manual memory management like C, but a productivity degradation over languages with deterministic automatic memory management like C++ and Rust. GC manages only memory, while in the latter case, you get automatic management of resources of any type, which can be a huge productivity boost if you use it to your advantage.

Do you want an example for C++? Lock free data structures are PhD level skillset unless there is some kind of tracing GC algorithm being used.

Also RAII is great and all, yet there lots of ways to get it wrong.

Badly implemented destructors, missing virtual destructors in hierachys, throwing exceptions on destructurs, not using handle types on heap allocated data, incorrect pairing of allocators.

Lock-free data structures is a 0.001% niche, which can be implemented as libraries by experts and then used without any trouble by an average Joe programmer. An average Joe wouldn't get the implementation of them right even in a GC language anyway. Also, in those niche cases, GC is available as an option. But you should not optimize the language for the niche use case.

> Badly implemented destructors, missing virtual destructors in hierachys, throwing exceptions on destructurs, not using handle types on heap allocated data, incorrect pairing of allocators.

Those seem to be more specific problems with C++ rather than RAII. Rust has none of those.

The ongoing issues with Drop trait stabilization show otherwise.

Having a GC is an option alongside the other ones, an option that both Epic and Microsoft think it is worth enough money to spend development resources on.

And Google as well, actually, as Chrome uses a C++ GC, seen as way to fix security issues, Olipan.

GC as an opt in, next to to RAII - so you can use it when you need it, that's fine. But it is a productivity issue when the only way to manage memory is non-deterministic GC, e.g. like in Java or Go.

That was the original question, why there are GC implementations for C++.

Every language with a GC is distinct, and should be properly analysed instead of putting all into the same box.

Demanding proof is a cop out. From microservice architectures to line length limits, there's no proof for basically any engineering decisions we make daily.

GCs can be more efficient if you alloc/free memory very often. shared_ptr can be quite slow because of the bookkeeping. It can also help bring more consistent performance, ie. one big malloc instead of millions of small ones.

I would think destructors would negate some of the performance advantages of GCs, since it's not possible to have zero-cost freeing of objects when destructors exist.

SGCL executes the destructors in a separate thread, so there is no cost to the mutator.

> SGCL executes the destructors in a separate thread, so there is no cost to the mutator.

Firstly, that's orthogonal to my original point is that, for example, a semi-space nursery can significantly reduce the cost of short-lived allocations (often being faster than malloc/free on such a workload), but only if there are no destructors.

Secondly, threads typically share resources so running something on a different thread does not magically cause it to not disturb the mutator. Such a claim makes me start to doubt the "real-time" claim in the title...

Disruption is a lower cost than the cost of executing the destructor by the mutator.

One example would be to create higher level languages that compile to / interoperable with C++

GC can be faster and allocate less memory.

tracked_ptr: 279.95ms (151MB)

shared_ptr: 1035.07ms (480MB)

source: https://godbolt.org/z/jP7ohPehY

This introduces the tracked smart pointer. This pointer has less overhead than shared_ptr and releases circular data structures.

You use custom memory management where it matters, gc anywhere else.

The intention of creating this project was the opposite. You only use the tracked pointer when it is beneficial.

Well that'd work too :)

The adoption of a particular memory allocation strategy depends on a lot factors. This is C++ after all.

Reply on news.ycombinator.com