Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does memory leak? (1995)

groups.google.com

Post reply on HN
Print view View original

31–40 of 289 posts

Re: Does memory leak? (1995)

#31

Post by mannykannot »

simias wrote: post #13

I think it's a bad mindset to leak resources even when it doesn't effectively matter. In non-garbage collected languages especially, because it's important to keep in mind who owns what and for how long. It also makes refactoring easier because leaked resources effectively become some sort of implicit global state you need to keep track of. If a function that was originally called only once at startup is not called r…

I think you are conflating two issues: while one should understand who owns what and for how long, it does not follow that one should always free resources even when it is not necessary, if doing so adds complexity and therefore more things to go wrong, or if it makes things slower than optimal.

In this particular case, correctness was not primarily assured by a massive amount of testing (though that may have been done), but by a rigorous static analysis.

Re: Does memory leak? (1995)

#33

Post by tyingq »

mojuba wrote: post #8

One other class of applications that don't really require garbage collection is HTTP request handlers if run as isolated processes. They are usually very short-lived - they can't even live longer than some maximum enforced by the server. For example, PHP takes advantage of this and allows you not to worry about circular references much.

"For example, PHP takes advantage of this"

I imagine the various long-running PHP node-ish async frameworks curse this history. Though PHP 7 cleaned up a lot of the leaks and inefficient memory structures.

Re: Does memory leak? (1995)

#34

Post by [deleted] »

kleiba wrote: post #17

Seems a bit unlikely to me. Intuitively, calculating how much memory a program will leak in the worst case should be at least as much effort as fixing the memory leaks. And if you actually calculated (as in, proved) the amount of leaked memory rather than just by empirically measuring it, there's no need to install double the amount of physical memory. This whole procedure appears to be a bit unbelievable. And we're…

[deleted]

Re: Does memory leak? (1995)

#35

Post by matsemann »

I made a project a few years back where I had really no idea what I was doing. [0] I had to read two live analog video feeds fed into two TV-cards, display them properly on an Oculus Rift and then take the head tilting and send back to the cameras mounted on a flying drone. I spent weeks just getting it to work, so my C++ etc was a mess. The first demo I leaked like 100 MB a second or so, but that meant that it would work for about a minute before everything crashed. We could live with that. Just had to restart the software for each person trying, hehe.

[0]: https://news.ycombinator.com/item?id=7654141

Re: Does memory leak? (1995)

#36

Post by mantap »

MrBuddyCasino wrote: post #15

Why go through the trouble of a) calculating maximum leakage b) doubling physical memory instead of just fixing the leaks? Was it to save cycles? Prevent memory fragmentation? I feel this story misses the details that would make it more than just a cute anecdote.

It's possible it may have been running on bare metal without an OS. Maybe they didn't want to verify a memory allocator and just treated the whole program as one big arena. I presume by "calculating" they meant "run the program in worst case conditions and see how much memory it uses".

Re: Does memory leak? (1995)

#37

Post by Out_of_Characte »

What an interesting concept. Good programmers always consider certain behaviours to be wrong. Memory 'leaks' being one of them. But this real application of purposefully not managing memory is also an interesting thought exercise. However counter intuitive, a memory leak in this case might be the most optimal solution in this problem space. I just never thought I would have to think of an object's lifetime in such a literal sense.

Edit; ofcouse HN reacts pedantic when I claim good programmers always consider memory leaks wrong. Do I really need to specify the obvious every time?

Re: Does memory leak? (1995)

#38

Post by ken »

nneonneo wrote: post #24
kleiba wrote: post #17

Seems a bit unlikely to me. Intuitively, calculating how much memory a program will leak in the worst case should be at least as much effort as fixing the memory leaks. And if you actually calculated (as in, proved) the amount of leaked memory rather than just by empirically measuring it, there's no need to install double the amount of physical memory. This whole procedure appears to be a bit unbelievable. And we're…

Why is it hard to calculate? Suppose I maintain lots of complex calculations that require variable amounts of buffered measurements (e.g. the last few seconds, the last few minutes at lower resolution, some extrapolations from measurements under different conditions, etc.). Freeing up the right measurements might be really tricky to get right, and if you free a critical measurement and need it later you’re hosed. On…

Are you taking into account memory fragmentation? Or the internal malloc data structures? If your record were just 1 byte more, it could easily double the total actual memory usage.

Memory usage is discrete, not continuous. It's not as simple as calculating the safety factor on a rope.

Re: Does memory leak? (1995)

#39

Post by barrkel »

chapium wrote: post #16
mojuba wrote: post #8

One other class of applications that don't really require garbage collection is HTTP request handlers if run as isolated processes. They are usually very short-lived - they can't even live longer than some maximum enforced by the server. For example, PHP takes advantage of this and allows you not to worry about circular references much.

This is clearly not my subject area. Why would we be spawning processes for HTTP requests? This sounds awful for performance. My best guess is a security guarantee.

Killing a process is much safer than killing a thread, and the OS does cleanup.

It's not great for maximizing performance but it's not 100s of milliseconds either, forking doesn't take long; what is slow is scripting languages loading their runtimes, but you can fork after that's loaded. If hardware is cheaper than opportunity cost of adding new features (rather than debugging leaks) it makes sense.

Re: Does memory leak? (1995)

#40

Post by barrkel »

kleiba wrote: post #17

Seems a bit unlikely to me. Intuitively, calculating how much memory a program will leak in the worst case should be at least as much effort as fixing the memory leaks. And if you actually calculated (as in, proved) the amount of leaked memory rather than just by empirically measuring it, there's no need to install double the amount of physical memory. This whole procedure appears to be a bit unbelievable. And we're…

The control flow graph will most likely be a loop doing PID; I think it could be statically analysed.
Post reply on HN