Difference between revisions of "Garbage collector"

From HaskellWiki
Jump to navigation Jump to search
(Category:Glossary)
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. Garbage collection is also a bit difficult to handle with respect to real-time processing.
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.
 
   
 
== See also ==
 
== See also ==

Revision as of 00:09, 3 January 2009

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.

See also