Hacker News Reader

Comment by SmooL | Hacker News Reader

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

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

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.

Reply on news.ycombinator.com