Hacker News Reader

Comment by mailslot | Hacker News Reader

Seems like we could just as easily stop using garbage collection. ... or even go back to reference counting / smart pointers and just live with the “limitation” that we can’t have circular references.

View on HN

Reference counting nor "manual" memory management are not faster than GC by themselves. Both tend to have pretty bad slowdowns that tend to result in optimizations... By batching operations similar to "GC pass", because there are different metrics of performance and occasional pause appears to be good compromise for most.

Personally I'm partial to deterministic schemes akin to IBM Metronome, where GC runs in bounded static time.

Why scare quote "limitation"? It literally is a limitation, since it prevents me from doing something in code that can be useful at times. It certainly has tradeoffs.

It's not a hard limitation, the fallback is some degree of manual memory management.

Which has been shown time and time again to be the source of many serious software bugs and exploits

oooo manual memory management scary. the absolute state of web programmers today

I have over a decade of professional experience entirely in C and C++. I believe that manual memory management is the wrong choice for the vast majority of applications. It is error prone and often slower than garbage collection.

if you have a decade of C then you know its not slower unless mistakes are made

if you believe that then you have no idea how Garbage Collectors work, period.

Please explain why half of optimizing java involves statically pre-allocating memory and trying to avoid the automatic memory management then

This...isn’t true.

Could you give any examples of common use cases and ways that people perform these “optimisations”?

Not necessarily common because garbage collected languages tend to not get used for high performance tasks, but a huge amount of modern optimization is in improving contiguous memory access and avoiding pointer chasing to use CPU cache more effectively, in java allocating arrays of primitives type is about the only way to do that. Similarly in c# they added spans to achieve this with better ergonomics, but both basically come down to avoiding the garbage collector for better performance.

Another big one is trying to allocate as much as possible on the stack, either through the language like c/c++/c# or by using local variables and hoping the compiler will do the right thing for you with java. A lot of the work gone into java vm's over the decades have been trying to improve this. Even java sacrifices it's OO purity to make integers and floats value types on the stack, that was to get non-laughable performance.

> This...isn’t true.

It's not even remotely controversial, saying garbage collection is slower is like saying water is wet.

Sure, if you’re using pre-1990’s memory management. Best practices have evolved far beyond the explicit use of malloc & free and unsafe string handling.

Most popular dynamic languages don’t use garbage collection under the hood anyway. In Python and many other runtimes, it’s primarily reference counted.

Python still uses mark and sweep occasionally to clean up structures where reference counting fails.

It has optional cycle detection, yep. But... you could also just spend a couple of minutes to not have cyclic references.

Closures are objects that can participate in cycles. And the lifetime of closures is very hard to track statically.

They are and they should be used responsibly. I’d argue sparingly also.

"A couple of minutes"

Just a little bit overconfident.

Python largely only gets away with ref counting because it doesn't support concurrent access. The GIL means it's basically single-threaded ref counting, which is much cheaper than an actual atomic ref count (like std::shared_ptr)

Scattering atomic ref counts everywhere gets extremely expensive very quickly.

I'd be willing to wager you use plenty of software, codecs, games, and more that would not function nearly half as well without carefully managed memory.

Carefully managing memory often means using a language feature that handles the bulk for you. Neither manual nor GC. And you can be careful about how you use memory even in the presence of a GC, getting the same kind of optimization without any safety risks. It's not a tradeoff between manual management and "who cares?".

Many tracing GC algorithms are considerably faster than reference counting.

Depending on the workload different memory allocation strategies perform better or worse. GC systems usually even have the fastest allocation. The only problem is that you see deallocation as one big block that is completely disconnected from allocation.

In throughput-optimized GC setups (not latency optimized) that's the case. Though free(), despite being seemingly "constant", can have unpredictable pause times as well when you hit a bad point.

Why limitation in quotes? Do you feel it is not one in practice?

I argue that some limitations, like clear resource ownership, are good... but there are still workarounds that aren’t too arduous. Weak pointers and the like are decent enough abstractions to handle the rare case... or just going manual. It’s not a limitation in practice, no.

It hasn’t been a problem for me in over a decade in a multitude of languages. On Java codebases? I’ve witnessed some frightening levels of sloppiness that are only solvable with a profiler.

Reference counting is already slower than having a GC in most practical applications, not to mention that having no circular references may make the code where you need 'em either slower or means you'll have to write a workaround, which is often also overhead and makes things more complicated.

The benefit of not using GC is improved understanding of the code and a better architecture. These things will also lead to better performance.

GC was a mistake. The main reason it is still used outside scripting languages is the notion that non-GC languages need to be low level. Which in practice is kind of true just because we haven't had any real competition in that area.

Gc was a mistake? On what possible authority can you make such a claim?

It's not that controversial of a statement. The choice has largely been dictated by the fact that non-GC meant C or C++, and it is not hard to find reasons to avoid them.

Now we also have rust, but rust is new and also has a low-level aura, making comparisons to high-level languages difficult.

That Go has a GC is a shame, such a missed opportunity.

Not having GC in no way improves understanding of architecture or gives better performance. Hordes of C/C++ programmers that don't understand memory management but swear by malloc()/free() are a good example of that. And it's not like C/C++ are only language without GC, they are just popular now.

Typical programmer is taught nothing about memory management, till maybe they learn bits and pieces (often by hearsay and cargo culting). It doesn't matter if we're talking manual or automatic. Without such understanding one cannot write performant code or make a good architecture.

Also - a good working definition of low-level language is language that makes you care about things irrelevant to your task...

Not necessarily no. Just as having type information doesn't lead to a better program.

But it helps. And is something you need to reason about regardless. Being explicit about it isn't a huge overhead but has lots of benefits.

Being explicit usually means that you have to drop whole classes of optimizations, or manually perform the analysis yourself (probably resulting in errors).

Being explicit gives the compiler more information to work with, enabling more optimizations.

Ref counting is worse than GC. Ref counting: deeper pipelines, branch predictor extra load.

And when you need multithreaded/concurrency it goes to atomic operations, cache coherency traffic, memory and compiler barriers.

Why would a reaction to a faster / low resource GC method be to stop using GC?

Because people aren't taught about GC or memory management at all, so cheap soundbites about "GC being bad" from old survives as "wisdom"

doesn’t seem cool to admire Apple technologies, but ARC seems to work amazingly well with zero CPU overhead

It’s not zero — those -retain and -release calls still exist when necessary and have a small penalty — but it does minimize them well, and is lower overhead and vastly more predictable than GC.

It's a little better than that, because the overhead of ObjC method dispatch is avoided. There are no calls to -retain or -release (if the receiver hasn't overridden those methods), it's just a C function call to objc_release et al. No objc_msgSend involved.

It's not at all zero CPU overhead, not even close. retain & release are thread-safe, meaning atomic ref count. Very comparable in cost to std::shared_ptr<T> or Rust's Arc<T>. Both of which also automatically insert the calls to inc & dec ref counts.

It's cool that you don't need to bother with specifying the type as being std::shared_ptr<T> or Arc<T>, but it's not particularly novel, either. It's "just" syntax sugar (or lack of syntax sugar I guess?)

Almost but not quite. Clang has very special rules around ARC that allow it to perform additional optimizations that would otherwise be illegal [1].

[1] https://clang.llvm.org/docs/AutomaticReferenceCounting.html#...

That just lets it release earlier, not retain/release less often.

ARC can't do anything magic here vs. something like really careful use of std::move & const references.

ARC optimizations do let it retain/release less often. For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.

> For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.

Are you just referring to standard RVO? If you return a std::shared_ptr in C++ today you won't get the equivalent of retain+release, either, RVO avoids that.

Did you even take a look at the doc I posted?

> For example, if the user puts logging statements in retain, they should not be surprised if those statements are executed more or less often depending on optimization settings

> In general, ARC does not perform retain or release operations when simply using a retainable object pointer as an operand within an expression

> However, C and C++ already call this undefined behavior because the evaluations are unsequenced, and ARC simply exploits that here to avoid needing to retain arguments across a large number of calls.

> ARC performs no extra mandatory work on the caller side, although it may elect to do something to shorten the lifetime of the returned value.

>retain & release are thread-safe

That's optional tho, and I never use it that way.

Do you have a link to what you're referring to? Apple's docs clearly state retain/release are thread safe.

Are you using your own implementation of retain & release or something?

For sure. It's entirely stock:

  @property (strong, nonatomic) UIView* unselectedTabsView;

"nonatomic" means avoid synchronization code. This code is not thread safe for that reason, but I never do cross-thread access anyways.

That means reads of/writes to the property are nonatomic. Certain (not all) ARC refcount functions are required to be atomic no matter what.

Reply on news.ycombinator.com