Difference between revisions of "Garbage collector"

From HaskellWiki
Jump to navigation Jump to search
(short explanation)
 
(how memory leaks slow down the garbage collection)
 
(2 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
This way, in Haskell memory deallocation can be hidden, making the language (more) [[declarative]].
 
This way, in Haskell memory deallocation can be hidden, making the language (more) [[declarative]].
   
A simple idea of implementing a garbage collector would be to count the references to an object
+
A simple idea of implementing a garbage collector would be to count the references to an object and delete the object when the last reference disappears.
 
However, in cyclic data structures like <hask>let x = 'a':x in x</hask>, the <hask>x</hask> is referenced by itself, so it would never be deallocated. Thus garbage collection is a bit more complicated and thus needs more effort and phases, where it is applied.
and delete the object, when the last reference disappears.
 
  +
However in a cyclic data structures like <hask>let x = 'a':x in x</hask>,
 
the <hask>x</hask> is referenced by itself, so that it would never get deallocated.
 
Thus garbage collection is a bit more complicated and thus needs more effort and phases, where it is applied.
 
 
Garbage collection is also a bit difficult to handle with respect to real-time processing.
 
Garbage collection is also a bit difficult to handle with respect to real-time processing.
  +
You cannot precisely control when something gets deallocated and in real-time processing the garbage collector might just choose the wrong time point.
  +
However, in long running (server) applications you might encounter [[memory leak]]s that are not easily observed in programs that run only a short time.
  +
A memory leak does not only mean that more and more memory is allocated
  +
but it also means that the garbage collector has to verify the reachability of an increasing number of pieces of data.
  +
   
 
== See also ==
 
== See also ==
   
 
* [[Research_papers/Runtime_systems#Garbage_collection Research papers]]
 
* [[Research_papers/Runtime_systems#Garbage_collection Research papers]]
  +
  +
[[Category:Glossary]]

Latest revision as of 23:45, 18 June 2010

A garbage collector deallocates unused allocated memory from time to time. This way, in Haskell memory deallocation can be hidden, making the language (more) declarative.

A simple idea of implementing a garbage collector would be to count the references to an object and delete the object when the last reference disappears. However, in cyclic data structures like let x = 'a':x in x, the x is referenced by itself, so it would never be deallocated. Thus garbage collection is a bit more complicated and thus needs more effort and phases, where it is applied.

Garbage collection is also a bit difficult to handle with respect to real-time processing. You cannot precisely control when something gets deallocated and in real-time processing the garbage collector might just choose the wrong time point. However, in long running (server) applications you might encounter memory leaks that are not easily observed in programs that run only a short time. A memory leak does not only mean that more and more memory is allocated but it also means that the garbage collector has to verify the reachability of an increasing number of pieces of data.


See also