[mannykannot]

It is not just a heuristic if you have hard upper bounds on the things that matter - in that case, it is static analysis. A missile has a limited, and well-defined, fuel supply.

In the case of memory management, it is not enough to just free it after use; you need to ensure that you have sufficient contiguous memory for each allocation. If you decide to go with a memory-compaction scheme, you have to be sure it never introduces excessive latency. It seems quite possible that to guarantee a reallocation scheme always works, you have to do more analysis than you would for a no-reallocation scheme with more memory available.

[jldugger]

This depends entirely on the mode of operation which I suspect neither of us know in great detail; if in any circumstance the runtime of the program is not tied to expenditure of fuel you have literal ticking time bomb.

Ideally we'd be able to tie such assertions into a unified static analysis tool, rather than having humans evaluate conflicting analyses. And god forbid the hardware parameters ever change, because now you need to re-evaluate every such decision, even the ones nobody documented. Case in point: Arianne 5 (not exactly my original scenario, but exactly this one -- 64bit -> 16 bit overflow caused a variety of downstream effects ending in mission failure).

[mannykannot]

Well, yes, I already explained that it depended on circumstances, and just let me add that I would bet the engineer quoted in the article (explaining that the memory leaks were a non-issue) knew much more about the specifics than either of us.

The Ariane 5 issue is not, of course, a memory leak or other rescource-release-and-reuse issue. It is a cautionary tale about assumptions (such as the article's authors assumption that memory leaks are always bad.)