4

This question already has an answer here:

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.

use utf8; use strict; use warnings; print("Hello World!\n");

Python 3.5 leaks 456,502 bytes.

print("Hello World!")

SpiderMonkey 24 leaks 79,325 bytes.

print("Hello World!")

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

marked as duplicate by ratchet freak, Bart van Ingen Schenau, TMN, gnat, GlenH7 Mar 13 '16 at 16:12

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • "acceptable" in this context is very subjective. – MetaFight Mar 11 '16 at 11:13
  • 12
    Memory leaks in long running processes are mainly a problem is the leaks accumulate. Your examples might well be due to the runtime not bothering to run the GC because the program terminates before the GC triggers, whereas for a long running process the GC would eventually trigger. – CodesInChaos Mar 11 '16 at 11:34
  • 4
    How do you know those are memory leaks and not resources that would have been released by the memory manager at a later time, if you had allowed the program to run longer? How do know it's not a resource pool? – Jörg W Mittag Mar 11 '16 at 12:32
  • 1
    You might want to edit your question to be more clear that Valgrind checks for leaks in the runtime itself, rather than application-level resources that are subject to garbage collection. Although to be honest, I don't think this question is answerable without a maintainer coming here and saying "we've never run Valgrind on our code, so we have no clue what leaks might be in it." – kdgregory Mar 11 '16 at 12:52
  • 1
    All Ruby and Python engines I know of have automatic memory managers. YARV has a fairly simple mark-and-sweep tracing collector. Rubinius has a tracing collector based on the Immix paper. CPython has a reference counting collector combined with a simple mark-and-sweep tracing collector. PyPy has a region-based collector, I think. JRuby, IronRuby, Jython, and IronPython don't have their own memory managers, they rely on their host platform. Rakudo Perl is similar, I believe, it also doesn't manage its own memory but relies on the host (Parrot, Moar, or JVM). – Jörg W Mittag Mar 11 '16 at 12:55