Hacker News Reader

Comment by mattpallissard | Hacker News Reader

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

View on HN

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.

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.

> 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++.

Reply on news.ycombinator.com