Hacker News Reader

Comment by bnolsen | Hacker News Reader

In language garbage collection just makes implementing a compiler that much harder to do and frankly bloats up the runtime. Basic c++ shared pointers take up pretty much 90+% of what people need in GC (non stupid software architecture decisions should make up the remaining 10%).

I have seen problems with stalling caused by kernel memory heap defragging on linux resulting in some serious thrashing. What that means is that the issue of heap fragmentation can be a problem regardless of which language used.

View on HN

"In language garbage collection just makes implementing a compiler that much harder to do"

A simple copying or mark-and-sweep collector is far easier to write than even basic dataflow-analysis optimizations. Implementor effort is hardly an argument against garbage collection; implementing efficient garbage collection is no worse than implementing a good optimizer or efficient code generation.

"Basic c++ shared pointers take up pretty much 90+% of what people need in GC"

They do so in a way that is right in the programmers face, adding needless effort to writing software, and can actually wind up being slower than a modern garbage collector. Shared pointers are a mistake, not quite as bad as auto_ptr but pretty bad nonetheless; the committee should have just introduced a garbage-collected smart pointer class and kept things simple (I guess that would not be the C++ way, though).

Reference counting, even ignoring the additional expense C++ places on std::shared_ptr by requiring it be thread safe, is far too slow for allocation heavy languages. Only "we don't give a damn" implementations (like CPython) use it, because it is simply not competitive.

Not necessarily true. See "Down for the Count?" ISMM 2012: http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...

"This brings the performance of reference counting on par with that of a well tuned mark-sweep collector."

I'm not really convinced. How well does it stack up when the competition is a copying generational collector?

They compare against a copying collector.

... implemented in Jikes RVM which is very far behind Oracle JVM. Herz and Berger (2005) based their experiment on Jikes RVM, too, and incorrectly concluded that GC needs 5x more memory to have acceptable performance comparable to malloc/free. Someone else redid their experiments using Oracle JVM and it turned out that it was not 5x, but 20%.

shared_ptr may be slow (I don't know) but you actually make very little "garbage" in C++, so it's not a problem. You're simply forced by the language to have clear ownership of resources most of the time.

This, and if you're using shared_ptr heavily in C++, you're probably doing it wrong, since unique_ptr is usually sufficient. (You could say that shared_ptr has the advantage that you don't have to think about who owns what, but with C++ there's no way around doing some amount of thinking about that, lest you get cycles.)

That's a reasonable defense of std::shared_ptr, but I was not discussing C++ code (I was careful to mention "allocation heavy languages" in my post).

Objective-C uses ref counting and does alright... Hardly a language that doesn't prioritize performance.

Objective-C, a language which uses dynamic dispatch for all method calls and does not do any kind of type-specialized code generation, certainly does not prioritize performance.

It priorities performance in one important respect: by providing direct access to C. It's common in many languages to write performance critical sections in C or even assembly. This is trivial in ObjC, which has C as a subset, so it is done more often than in e.g. Python or Java.

Interoperability with FFIs is one of the advantages of reference counting over GC. You don't have to worry about pinning allocations, allocation coloring, unscanned roots, etc. The ObjC refcounting operations (CFRetain/CFRelease), and the collection types (CFArray, CFString, CFSet...) are all trivially available from C as well.

I speculate that this better interoperability with C is why Apple deprecated GC and went with ARC. We can see Microsoft sort of moving in the same direction with WinRT.

I guess the phrase "prioritize performance" is maybe ambiguous. It's a language that cares a lot about performance, let's say -- sure, it uses dynamic dispatch for its method calls (losing a little speed compared more-static C++ virtual methods, which themselves lose a little speed compared to non-virtual methods), but the implementation itself is very optimized (there's some good blog articles describing the implementation, but I don't have them at hand), and you always have normal function calls as in C if you need maximum speed (as millstone mentioned). C really feels like a first-class language when using Objective-C, and C is a pretty damn fast language.

(As an aside, there was an optional GCed variant of objective-c around for a while. Not sure what the performance impact was vs ref counted.)

iOS uses Automatic Reference Counting (ARC, http://en.wikipedia.org/wiki/Automatic_Reference_Counting) by having the compiler add reference counting instructions, while refraining from having the developer add tedious reference counting instructions themselves. I'm not sure if there are significant performance advantages over proper GC.

It's worth noting that Apple has implemented GC in Objective-C on OS X before, but deprecated that in favour of its ARC implementation -- probably because its garbage collection implementation was no good at all (performance-wise).

iOS is a technology swamp.

Apple dropped GC in Objective-C, because they never managed to make it work properly.

By the time ARC was announced, there were still lots of corner cases in the ways code compiled with GC was interacting with code that wasn't compiled with GC enabled.

Plus, if you check Apple's developers documentation from those days, great care was required to make sure the GC could play nice with the C part of Objective-C.

So, in reality the ARC approach was taken, because it was the only way to have a working automated memory management, compatible with Objective-C code overall. Of course, being Apple, they sold it as a better solution for memory management and not as a result from their failure to implement a sound GC for Objective-C.

std::shared_ptr is not thread safe, only the control block shared between all of the std::shared_ptr objects is thread safe. This means you only get a locking penalty when shared_ptr objects are constructed, copied, or destroyed, but not moved, dereferenced, or casted.

Both construction and destruction will allocate or can release memory, respectively, which I would think would bottleneck before any atomics or memory barriers inside shared_ptr. To me, the first likely port of call for improving performance in these cases is therefore a custom memory allocation strategy like a memory pool.

Copying can be a concern, but most containers and standard algorithms should be move aware now. You should be moving shared_ptr's far more often than you copy them.

All that aside, thread-safe by default seems to be the sane decision in this era.

Unless you happen to have a compacting GC. :)

Well since compacting means the expensive task of moving managed memory blocks around to free larger sections that solution certainly comes with a big penalty of it's own.

Better to avoid heap fragmentation to such extents by applying a better allocation strategy imo.

That is why generational collectors are so good. It is not common to have huge blocks of memory than also happen to be short lived, and if you do have such a design, you can probably refactor it (or just not use garbage collection there, which any production-grade programming environment should allow by some means).

shared pointers? You must be joking!

Reply on news.ycombinator.com