Difference between revisions of "Memory leak"

From HaskellWiki
Jump to navigation Jump to search
(detection of a memory leak)
(makeXs: make the upper bound an argument)
Line 3: Line 3:
 
A garbage collector can reliably prevent [http://en.wikipedia.org/Dangling_pointers dangling pointers],
 
A garbage collector can reliably prevent [http://en.wikipedia.org/Dangling_pointers dangling pointers],
 
but it is easily possible to produce memory leaks, especially in connection with [[lazy evaluation]].
 
but it is easily possible to produce memory leaks, especially in connection with [[lazy evaluation]].
 
Note that a leak will not only consume more and more memory but it will also slow down the [[garbage collector]] considerably!
  +
Maybe it is even the reason for the widely spread opinion
  +
that garbage collectors are slow or not suited for [[realtime]] applications.
  +
  +
== Types of leaks ==
  +
  +
=== Holding a reference for a too long time ===
   
 
Consider for example:
 
Consider for example:
Line 16: Line 23:
 
we like to achieve this by turning the list definition into a function with a dummy argument.
 
we like to achieve this by turning the list definition into a function with a dummy argument.
 
<haskell>
 
<haskell>
let makeXs _ = [1..1000000::Integer]
+
let makeXs n = [1..n::Integer]
in sum (makeXs False) * product (makeXs True)
+
in sum (makeXs 1000000) * product (makeXs 1000000)
 
</haskell>
 
</haskell>
 
A memory leak will not only consume more and more memory but it will also slow down the [[garbage collector]] considerably!
 
   
 
== Detection of memory leaks ==
 
== Detection of memory leaks ==

Revision as of 05:57, 24 June 2010

A memory leak means that a program allocates more memory than necessary for its execution. Although Haskell implementations use garbage collectors, programmers must still keep memory management in mind. A garbage collector can reliably prevent dangling pointers, but it is easily possible to produce memory leaks, especially in connection with lazy evaluation. Note that a leak will not only consume more and more memory but it will also slow down the garbage collector considerably! Maybe it is even the reason for the widely spread opinion that garbage collectors are slow or not suited for realtime applications.

Types of leaks

Holding a reference for a too long time

Consider for example:

let xs = [1..1000000::Integer]
in  sum xs * product xs

Since most Haskell compilers expect, that the programmer used let in order to share xs between the call of sum and the call of product, the list xs is completely materialized and hold in memory. However, the list xs is very cheap to compute, and thus it would reduce memory usage considerably, if xs is recomputed for both calls. Since we want to avoid code duplication, we like to achieve this by turning the list definition into a function with a dummy argument.

let makeXs n = [1..n::Integer]
in  sum (makeXs 1000000) * product (makeXs 1000000)

Detection of memory leaks

A memory leak can be detected by writing a test that should require only a limitted amount of memory and then run the compiled program with restricted heap size. E.g. you can restrict the heap size to 4 MB like in this example: $ ./mytest +RTS -M4m -RTS