Hacker News Reader

Comment by gizmo686 | Hacker News Reader

Memory bugs is an entire class of bugs that we have simply solved. If you use a language with a modern garbage collector (e.g. one that can handle cycles), you will very likely go an entire project without running into a single memory bug. To a first approximation, these bugs were not replaced with other bugs; they are simply gone. Further, we do not ask anything more of the programmer do accomplish this. Instead, we need the programmer to do less work than they would need to do with manual memory management.

That is not to say that garbage collection is an unambigous win. There are real downsides to using it. But for most programs, those modern garbage collectors are good enough that those downsides just don't matter.

View on HN

> you will very likely go an entire project without running into a single memory bug

Sure, you haven't lost the handle to the memory, but you can still "leak" memory with a GC. Happens all the time. Add to data structure at state 1, do something in state 2, remove data in state 3. What happens you never hit state 3?

> But for most programs, those modern garbage collectors are good enough that those downsides just don't matter.

I mostly agree with this. Although, most programs hit a point where you have to be aware what the GC is doing and try to avoid additional allocations. Which isn't very ergonomic at times. And is often more fucking around than manual memory management, just concentrated to a smaller portion of the code base.

Are you calling just allocating memory you’ll never use leaking? It is not. It is recoverable because for it not to be GC’d it has to be someone accessible. A memory leak means you lost the pointer to the memory, so now you can’t free it.

lost can include you don't know where to find it even though you know it exists...

>Are you calling just allocating memory you’ll never use leaking? It is not.

Yes it is, by definition a memory leak is any memory that has been reserved but won't be read from or written to. If you allocate memory into a data structure and after some point in time you will never read from or write to that memory, then that memory constitutes a leak.

There are (at least) 2 definitions of memory leak.

The upsides of the definition you gave are that it's simple, well defined, and maximally precise (nothing that is safe to collect is considered live)

The significant downside to this definition is that it's uncomputable. To know if memory is used requires knowing if a loop halts.

The second definition of memory leak is "unreachability" which is a bit harder to nail down. It's a conservative approximation of the first definition, but is more popular because it's computable, and it's practical to write programs with or without GC that don't leak

The latter definition is not particularly useful for writing programs that run on hardware with finite memory. End users don't care whether or not the allocations are reachable when your program uses all the memory in the system and crowds out other programs, slows, and/or crashes.

That could also potentially be a cache in a highly unused program.

I'm OK with people using the expression "memory leak" to mean "unbounded growth in heap size over time". The case that I see most frequently is a routine that's set up like "use some memory, wait until an event that never happens happens, free memory". Technically if you let time run indefinitely, the memory would be freed. But since memory is finite, eventually you run out and your program crashes, which is annoying in this case.

> A memory leak means you lost the pointer to the memory, so now you can’t free it.

that's an useless definition as otherwise it would be trivial to augment, say, malloc to prevent memory leaks.

I would define a leak as unused memory that it is not otherwise reusable by a program.

And this kind of leak is the same kind that is actually difficult to prevent and debug with manual allocation -- it's present / reachable in some structure, but not intentionally. Say you have a cache of items -- how big should it grow? Can it free space under memory pressure? If you reuse items, do they own collections (e.g., std::vec) that hold on to reserved but unused space (e.g. clear() doesn't free memory)? These are the hard problems and they are approximately the same with or without GC.

Joshua Bloch, of Effective Java fame, used the term unintentional object retention as a more precise term for memory “leaks” in garbage collected languages.

Seemes a bit pedantic, but so am I. I like that term.

I’ve also heard this referred to as Abandoned Memory, or sometimes a Space Leak. It’s a common class of bug in a reference counted language, like Objective-C, where cycles need special consideration.

Interesting, not really heard those terms, always "live leak". It's quite possible to introduce a live leak with manual memory management as well, though perhaps less seldom.

> Sure, you haven't lost the handle to the memory, but you can still "leak" memory with a GC. Happens all the time. Add to data structure at state 1, do something in state 2, remove data in state 3. What happens you never hit state 3?

What happens if you never escape a while loop? Should we ban while loop then? Bugs happen, we fix them. But I haven't had a memory bug in years outside of C and C++.

There is one downside, though it's not inherent to garbage collection, it just happens to correlate in current languages. Gc'd languages don't have raii, and for that reason they actually make you do more work when managing non-memory resources. The have been some attempts to work around this with e.g. pythons with, but In my opinion it's less ergonomic due to forcing indentation.

Go's defer works like RAII and does not introduce indentations.

    f := createFile("/tmp/defer.txt")
    defer closeFile(f)
    writeFile(f)

Even when the syntax does require indentation ("with" in python, "using" in C#) it's still pretty clean IMO.

Additionally, `using` no longer requires indentation in C#

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

TIL!

I just recently updated a few small services to C# 12 and there's a bunch of little niceties like this I'm finding (spread operator for instance).

Using also no longer requires inheritance from IDispose, it suffices that the type does support Dispose pattern, which is great when coupled with extension methods.

Using no longer requires a new scope block in more recent versions of C#

This misses the main benefit of RAII which is that you can't forget to close the file.

While not perfect, static analysis takes care of that, in similar veins C and C++ devs reach out to them for the language flaws.

Defer and context managers are a pale approximation of RAII. They are constrained to lexical scope, as opposed to RAII which works with object lifetimes. And it's the latter case which is much more error prone than 'oops, I forgot to close a file I opened this function'.

Do they?

    // Disposed when goes out of scope
    using var http = new HttpClient();
    var text = await http.GetStringAsync("https://example.org/");

They surely do, D for example.

Swift as another one, RC is a GC algorithm, before the usual clueless reply from people not educated in CS.

Followed by FP languages now adopting effects and linear type systems, alongside their automatic memory management approaches.

Even game engines (including unreal) use gc these days, which is nuts. Still though, it’s best to be careful with your allocations, use pooling, etc

Uncollectable reference cycles are shockingly easy to make in JS, especially with React. A classic example:

    function closure() {
        var smallObject = 3;
        var largeObject = Array(1000000);

        function longLived() { return smallObject; }
        function shortLived() { return largeObject; }
        shortLived(); return longLived;
    }

Will keep largeObject alive.

Is this a property of JavaScript or the engine running it? This feels like something a sufficiently-smart™ closure implementation should be able to prevent.

This is an artifact of V8's GC. Effectively, largeObject and smallObject are tracked together, as a unit. Splitting it out into two separate records increases average memory usage. They keep saying they want to fix it eventually, but it's been this way for 10+ years at this point.

You really do have to know the quirks of what you're targeting.

> sufficiently-smart™

Well, the reference lua implementation handles this case fine, and it's a solid but not at all smart™ codebase.

JS runtimes are allowed to optimize this out, IIRC, and will often do so.

This isn't an uncollectable reference cycle. It's true that with this code in most/all JS engines, if there's a reference to the function `longLived` then `largeObject` will be kept in memory, but reference cycles are collectable in standard garbage collection systems. Both of the values will be garbage-collectable once no outside references to `longLived` still exist. Pure reference counting systems (Rust Rc, C++ shared_ptr, etc) are the kind of system that fail to automatically handle cycles.

You could test this with your code by setting a FinalizationRegistry to log when they're both finalized, unset any outside reference to `longLived`, and then do something to force a GC (like run Node with --expose-gc and call `global.gc()`, or just allocate a big Uint8Array).

Geez! Didn't henry baker warn against implementing closures this way decades ago? This is an implementation bug—the code is fine.

Performance regression is a bug and GC has a horrific overhead in the average program. My computer is orders of magnitude faster than it was 15 years ago but it spends all of it's time wondering around in the wilderness hunting for memory to free. We could have just told it.

> those modern garbage collectors are good enough that those downsides just don't matter.

This is not what I see. Every I look at a profile of a program written in a GCed language, most of the time is spent in the garbage collector. I can't recall the last time I looked at a c++ profile where more than 10% of the time spent in new/delete. I have seen 100x speedups by disabling GC. You can't ship that, but it proves there is massive overhead to garbage collection.

> GC has a horrific overhead in the average program

It doesn't have to be that way. The BEAM is designed for tiny processes, and GC is cheap.

I love Erlang and BEAM, but the reason the GC is (mostly) cheap is because self-referential data structures are impossible, so you can have a very simple and yet still very effective GC. One heap per process also helps immensely.

Also, when your process has a giant heap, the GC gets expensive. There's been lots of improvement over the years, but I used to have processes that could usually go through N messages/sec, but if they ever got a backlog, the throughput would drop, and that would tend towards more backlog and even less throughput, and pretty soon it will never catch up.

That sometimes happens with other GC systems, but it never feels quite so dire.

Depends pretty much on what implementation one is specifically talking about.

Just like not all malloc()/free() were born equal, to the point companies did made big bucks selling specialised implementations.

I also speed up a function 100 times. It was concatenatign strings inside a loop. I changed it to used StringBuilder instead.

I could have disabled the GC to get the same speed up.

The article in question is about Ruby, which is garbage collected.

It's easy to get in trouble with an interconnected object graph: you mess up and hold onto a pointer that you shouldn't be holding onto, which results in a leak.

Reply on news.ycombinator.com