Garbage collection: Difference between revisions

← Older edit

Garbage collection (view source)

Revision as of 20:59, 2 June 2016

98 bytes added , 8 years ago

no edit summary

[unchecked revision]

VisualWikitext

Anonymous user

osdev>Ednutting

Revision as of 20:55, 19 December 2006 (view source) osdev>Walling (creating page from osfaq2)		Latest revision as of 20:59, 2 June 2016 (view source) osdev>Ednutting No edit summary
(4 intermediate revisions by 3 users not shown)
Line 1: '''Garbage Collection''' ('''GC''') is a [[memory management]] technique frequently used in high-level languages that allows the programmer not to worry about when memory areas should be returned to the system. Virtually all the [[object-oriented language]]s introduced after [[~~C PlusPlus\|~~C++]] provide some way of garbage collection (including Python, Java, Objective C). It can also be found in LISP or PERL, for instance. == How does it work? == Line 5: === Reference counting === The most basic implementation of garbage collection uses '''reference counting''': each object is associated with a counter that tells how many other objects refer to it. Say for instance you have a <tt>Disk</tt> object, every time your system needs another reference to that object (for instance because the <tt>DiskPartition</tt> object has a reference to the parent <tt>Disk</tt> object), the reference counter of <tt>Disk</tt> is incremented. Of course, if programmed manually, this is tedious and bugprone (although in C++ at least, the use of [[Smart_Pointer\|smart pointer]]s can automate this bookkeeping). Plus GC's solely based on reference counting will be unable to free self-referencing (or circular) structures, meaning that memory leaks are possible. === Mark & Sweep === A '''mark-sweep garbage collector''' traverses all reachable objects in the heap by following pointers beginning with the "roots", i.e. pointers stored in statically allocated or [[stack]] allocated program variables (and possibly registers as well, depending on the GC implementation). All such reachable objects are marked. A sweep over the entire heap is then performed to restore unmarked objects to a free list, so they can be reallocated. : ''Drawn from Hans Boehm's texts, see links below.'' Line 31: Whatever you chose to do, make sure that your garbage collector implementation is fully tested and stressed in a host environment before moving it into kernel space. And that missing a few garbage items is probably better than collecting live items :P The "Singularity" project (Microsoft Research, closed-source) ~~uses~~and the [http://www.flingos.co.uk FlingOS (educational OS, open-source)] both use GC everywhere, including in the kernel, so it can be done. Yet it needs to be done properly and it has important implications on your kernel design: * Using a single garbage-collected heap for every chunk of memory (both kernel and user) is probably a Bad Thing<sup>tm</sup>. You are most likely to have collected kernel-wide heap, collected process(/thread)-pinned heap(s) and uncollected kernel heap. * Having the garbage-collector freeze everything to work is unacceptable at kernel level, yet not all GC's require this (concurent mark & sweep being an example). * Garbage collection is often coupled with strong object typing and important restrictions on pointers arithmetic which might not be practical in C/C++ ... still under discussion. == ~~Forum references~~References == === Forum === * [http://www.osdev.org/phpBB2/viewtopic.php?t=11400 "Newbie Memory Management Question"] * [http://www.osdev.org/phpBB2/viewtopic.php?t=11332 "Digital Mars C/D compilers"] === ~~External references~~Websites === * [[wikipedia:Garbage collection (computer science)\|~~Garbage collection~~Wikipedia on ~~Wikipedia~~Garbage collection]] * http://www-128.ibm.com/developerworks/library/l-memory/ - IBM article about memory management * ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf - Microsoft Singularity Technical Report