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

21–30 of 289 posts

Re: Does memory leak? (1995)

#21

Post by daenz »

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.

"just fixing the leaks" can be a very time consuming process, involving hunting and refactoring (valgrind isn't perfect). It's very possible that just throwing more memory at it with the soft guarantee that the leak won't result in OOM may have been the best business decision for that particular contract. Of course it's not the "right" way to build a thing, but sometimes the job wants the thing now and "good enough."

Re: Does memory leak? (1995)

#23

Post by ptero »

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…

In a perfect world, yes. But in a hard real time system (and much of missile control will likely be designed as such), timing may be the #1 focus. That is, making sure that events are handled in at most X microseconds or N CPU cycles. In such cases adding GC may open a new can of worms.

I agree that in general leaking resources is bad, but sometimes it is good enough by a large margin. Just a guess.

Re: Does memory leak? (1995)

#24

Post by nneonneo »

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 the other hand, you can trivially calculate how many measurements you make per unit time, and multiply that by the size of the measurements to upper-bound your storage needs. Hypothetical example: you sample GPS coordinates 20 times per second, which works out to ~160 bytes/sec, 10000 bytes/min, or around 600KB for a full hour of flight. Easy to calculate - hard to fix.

Re: Does memory leak? (1995)

#25

Post by daenz »

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…

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

Why? I could calculate the average amount of leaking of a program much easier than I could find all the leaks. Calculating just involves performing a typical run under valgrind and seeing how much was never freed. Do that N times and average. Finding the leaks is much more involved.

Re: Does memory leak? (1995)

#26

Post by H8crilA »

ptero wrote: post #23
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…

In a perfect world, yes. But in a hard real time system (and much of missile control will likely be designed as such), timing may be the #1 focus. That is, making sure that events are handled in at most X microseconds or N CPU cycles. In such cases adding GC may open a new can of worms. I agree that in general leaking resources is bad, but sometimes it is good enough by a large margin. Just a guess.

It would be an acceptable solution if the memory supply would vastly outsize the demand, by over an order of magnitude. For example if the program never needed more than 100MiB and you'd install 1GiB or 10GiB. 10GiB is still nothing compared to the cost of the missile, and you get the benefit of truly never worrying about the memory management latency.

My favorite trick to optimizing some systems is to see if I can mlock() all of the data in RAM. As long as it's below 1TiB it's a no brainer - 1TiB is very cheap, much cheaper than engineer salaries that would otherwise be wasted on optimizing some database indices.

Re: Does memory leak? (1995)

#28

Post by FreeFull »

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…

A memory allocator without the ability to free memory is a lot simpler and faster. Usually though, I'd expect to see static allocation for this sort of code, I'm not sure why a missile would have to allocate more memory on the fly.

Re: Does memory leak? (1995)

#29

Post by qtplatypus »

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.

There is the cpu overhead of detecting where the memory goes out of scope and freeing it. So it can be a memory vs cup optimisation

Re: Does memory leak? (1995)

#30

Post by tyingq »

gameswithgo wrote: post #9
tyingq wrote: post #4

Until the cruise missile shop down the hall decides to reuse your controller.

If all software is built to protect against all possible future anticipated use cases, your software will take longer to make, perform worse, and be more likely to have bugs. If all software is built only to solve the problem at hand, it will take less time to develop, be less likely to have bugs, and perform better. It isn't clear that coding for reuse is going to get you a net win, especially since computing platfo…

Fair, but the leaks apparently weren't documented well, or the linked story wouldn't have read like it did.
Post reply on HN