[kleiba]

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 not even talking about code/system maintainability.

[FreeFull]

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.

[StupidOne]

Because he needed more memory mid-air? :)

Not sure was it pun or no pun intended, but you gave me a good laugh.

[daenz]

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

[kleiba]

Did you read in my original post the distinction between calculating and measuring a leak?

[nneonneo]

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.

[ken]

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.

[cozzyd]

If you don't free, malloc doesn't need all that overhead

[barrkel]

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

[kleiba]

And why couldn't it be freed?