This question already has an answer here:
- How important it is to fix memory leaks? 4 answers
I noticed that various scripting language interpreters leak memory even for very simple programs, like the canonical "Hello world!" program. To illustrate the problem with examples:
Perl 5.22 leaks 388,809 bytes.
Python 3.5 leaks 456,502 bytes.
SpiderMonkey 24 leaks 79,325 bytes.
(Valgrind shows memory leaked by SpiderMonkey as still reachable, but in 66 blocks - so it can't be excused by leaked emergency exception buffer in libstdc++)
Apart from the fact that in large programs memory management may become difficult and bugs appear, during my research, I discovered another reason for these leaks: Why bother with releasing memory if the OS will reclaim it after the process ends?
However, what if the process happens to be a long-running one? Is such an approach to memory management acceptable?
EDIT: I do believe my question is not a duplicate of How important it is to fix memory leaks?. That question is about memory leaks in user applications. I asked about memory leaks in "runtime environments" which do not have the comfort of knowing how exactly they will be used and therefore cannot make assumptions such as "we can let it leak, because the leaking function is called only once" or similar.
EDIT 2: (as suggested by @kdgregory) The question is not about the applications managing their memory, but about the memory management of the runtime itself (be it some internal data structures, temporary objects etc.). The Valgrind (which I used to check for leaks) does only see the runtime-level structures, and not application-level structures.