Talk:Garbage collection (computer science)

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Garbage collection (computer science) article.
Article policies
Archives: 1
This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.
Archive
Archives
1


Contents

[edit] Collection cycles

A collection cycle can occur at any time and can require an arbitrarily long amount of time to complete.

A collection cycle will only occur at a point where the program allocates dynamic memory, or when the program explicitly invokes garbage collection. It will not occur "at any time".

A collection cycle will not take an "arbitrarily long time". If we ignore environmental issues (e.g. VM paging, time-slicing), the time taken by a collection cycle is a typically a linear function of 1) the number of live objects, 2) the number of bytes of live objects, 3) the number of pointers in live objects, and 4) the number of dead objects. All of these numbers are bounded by the program's heap size. (For a copying or generational collector, you can ignore 4. For a non-copying, non-compacting collector you can ignore 3). --Anon

I should hope a typical garbage collector does not collect only when forced to or explicitly requested to. Process images would grow very large. This is only really acceptable if it's a machine-wide garbage collector. "Arbitrarily long time" isn't exactly true (indeed, every terminating program's runtime is trivially bounded by the number of machine states); more accurate might be "can cause a noticable pause that interrupts time-critical events". --Deco 03:01, 9 Feb 2005 (UTC)

Process images only grow while allocating memory. Therefore is in fact sufficient to perform collection cycles when a program allocates memory, as anon said. The process image won't grow arbitrarily large. However, from a programmer's point of view, GC may still happen at virtually "arbitrary" times, since (a) allocation is such a frequently used operation, and (b) even while a particular code doesn't make any allocations, another thread might allocate memory and cause a GC cycle. -- oefe

What if an application allocates objects and then executes for some long period of time without allocating anything more? Some of those objects allocated initially may no longer be in use, and yet the memory is not being freed, because no new objects have been allocated in the meantime and no explicit call has been made to actually free the now unused memory. 206.190.139.254 20:50, 27 February 2006 (UTC)

It usually doesn't matter. If you're on a virtual memory system, provided you don't exhaust virtual memory then the extra memory can get swapped out and performance is maintained (although the GC may be painfully slow if/when it finally occurs). If the GC is triggered regularly, then you're only marginally increasing the time/space footprint of the application. In addition, in some, but not all systems, the applications share a memory space, so the other other applications can trigger GC and tidy it up. If you don't have multiple applications running then it doesn't matter.WolfKeeper 17:02, 28 February 2006 (UTC)

This is an inherent property of tracing GC, so I'm not quite sure what you're getting at. You can argue that the problem you describe exists unless you GC every time you overwrite a reference, at which point reference counting would be a far better solution. Once you back away from that, it's all a matter of degrees :-) --Mike Lin 05:22, 28 February 2006 (UTC)

It's not inherent. Some real time garbage collectors run periodically, or you can sometimes (depending on the platform) trigger them to do that with a loop.WolfKeeper 05:55, 28 February 2006 (UTC)

It's inherent that objects will not be deallocated as soon as they are dereferenced under tracing GC. --Mike Lin 15:32, 28 February 2006 (UTC)

That's true, but not necessarily important. The fact that the objects are not being dereferenced doesn't usually matter unless something else needs the memory the unreferenced objects occupy, if something does want it, that should normally/ideally trigger a garbage collection (although may not in practice, if the application that needs it doesn't share the memory space; but if you're running on that sort of system, that's a good reason to run the GC sometimes even if memory isn't full.)WolfKeeper 17:02, 28 February 2006 (UTC)

My point was really just that I'd rather allocate and deallocate memory myself than rely on some background process to do it for me at some arbitrary time (if I'm explicitly calling the GC's 'free memory' function, why not just manage the memory myself?).  :)

Because you only call the GC from one part in the program, rather than thousands? Anyway, I've got a bead on you now, you're a masochist. Please stay away from me :-)WolfKeeper 18:31, 1 March 2006 (UTC)

However, ultimately, the engineer must look at the advantages and disadvantages of any particular approach and decide for his genderless self. In particular, relying on an automatic GC would make development faster, and also perhaps less prone to memory leaks, if you are unable to figure out how to deallocate things on your own.. 216.239.183.254 18:10, 1 March 2006 (UTC)

It's not a question of 'being able to', it's a question of having to. It's general experience that code that is written under a GC is maybe 30% shorter; and more reliable as well. In the past I wrote C++ code that automatically tidied up after its self, and those parts of the system that used it had very few leaks indeed (apart from one 'stellar' engineer whose code used the provided C compatibility interfaces interfaces incorrectly and reliably leaked; still even this is much better than unreliably leaking :-).) WolfKeeper 18:31, 1 March 2006 (UTC)

[edit] Performance information problems

In the performance paragraph, it is stated that the performance is "many" times higher for the C# case, allocating a lot of (small) objects, but there are no real-world results or any indication how to generate any. Furthermore, the reasoning is also flawed: heap managers for non-GC languages will also allocate in a linear fashion, and may have a linked list of free items for small sizes, so O(1). Added to that, this may cause memory to be used from CPU cache, which is much faster than cold memory. Also, the global (desktop) experience of programs having a lot of allocated memory but unused shouldn't be neglected. --Anon

I ran the prescribed experiment using MS Visual Studio 2005, with the C# version targeting .NET 2.0 and the C++ version compiling to native code, and default compiler options. (Please note this constitutes original research and so is ineligible for inclusion in the main article according to WP policy.)
$ time ./AllocTestSharp.exe
DING!

real    0m14.791s
user    0m0.015s
sys     0m0.015s

$ time ./AllocTest++.exe
DING!

real    4m34.446s
user    0m0.031s
sys     0m0.000s
--Cetin Sert 2007-11-01
I am a somewhat experienced C# programmer and looking at the C# source code, I would not expect any A objects to be created at all. The statement "A a = new A();" and the surrounding loop is very likely optimized away altogether: because neither i nor any A instance is referenced after the loop block so they can be optimized away without affecting the rest of the program logic. I suggest using a profiler to see whether any A instances are created at all. (Beware of the observer effect though.)
So the C++ version runs 18 times slower. Maybe there is something wrong with the Microsoft C++ allocator (this would explain a lot).
--Mike Lin 19:22, 5 February 2006 (UTC)
I agree with Anon, the explanation doesn't make sense. This sample code constantly allocates and frees a single block, so any reasonable memory manager is going to find the same block immediately and just return that. Microsoft's implementation may be broken, I don't know. But the proffered test doesn't measure what it's claiming to measure and is therefore irrelevant. And tthe claim advanced about superior performance is not factual and not NPOV; it's debated. See, for example, http://it.slashdot.org/comments.pl?sid=164766&cid=13751468
Let me illustrate my point about the test not testing what it claims. I reimplemented it in C (make A a struct type, and a static function for the constructor). Thus I am supposedly comparing the performance of C's malloc to C++'s new. I get the following results on a 3Ghz x86 processor (times are extrapolated from run counts that are 1/100th that in the original sample code):
language optimized? run in IDE? approx time (s)
C++ yes no 300
C yes no 400
C++ yes yes 2400
C yes yes 2500
C++ no no 300
C no no 700
C++ no yes 2600
C no yes 3200
You can see there's enormous variation here due to various other parameters changing, which means any comparisons between different systems are going to be doubtful in the first place; there's not necessarily any such thing as "the same settings"; e.g. perhaps C# optimizes much more by default. The non-optimized C vs. C++ were off by a factor of 2, which is difficult to explain. (The slowdown from running in the IDE is, I believe, because when running in the IDE a different memory allocator is used which initializes allocated memory to a known value.) Nothings 03:31, 10 March 2006 (UTC)
Clearly, the test is inherently flawed as a controlled comparison. And if the speedup was a factor of 2 or 3, I would agree; one could make a strong argument that externalities completely forbid drawing any meaningful conclusions from such an observation. I don't think the same is true with a handily order of magnitude speedup; given what the program is doing, I think you just have to blame this on the memory allocator, although it could just happen to be a crappy memory allocator for whatever reason.
Anyway, this debate aside, it does seem like the language in this section of the article should be revised, since the issues that one can raise with this example are a distraction from what is generally a valid and relevant point. Can someone propose a better illustrative example? Mike Lin 04:03, 10 March 2006 (UTC)
First of all, I actively disbelieve it's a valid and relevant point. There may be some cases where the memory management wins, but for most programs, using a good garbage collector in one and a good memory manager in the other, I don't think it's true. There have been lots of citations of 10% of the time in programs spent on garbage collection, and I've never seen the same claim about malloc/free. So personally I'd just kill the whole thing; it's a controversial claim, not a factual one.
Second, though, I'm much more concerned with seeing the bogus test deleted. Now, maybe there is a real performance difference here due to memory management. But given that the constructor has bogus code that any optimizer would reduce, it does not seem like a careful experiment to me. Perhaps C# always optimizes (somewhat), and the C++ was compiled non-optimized? (Note you said "default compiler options"; most IDE/compilers I used default to non-optimized.) Maybe the C# compiler does a reachability analysis and actually allocates the object on the stack. There are a lot of possiblities. Let me suggest a slightly altered comparison. I don't actually speak C#, so you'll have to tweak this to match. I hope you agree that this is not attempting to test anything the original test did not do, just make it much more unlikely for a compiler to optimize away the memory management.
C#
  class A {
        private int x,y;
        public A(int i) { x = i; y=i; }
  }
  
  class Example {
        public static void Main() {
               A array[16];
               for(int i = 0; i < 16; i++)
                       array[i] = new A(i);
                for(int i = 0; i < 1000000000; i++) {
                       array[i & 15] = new A(i);
                }
                System.Console.WriteLine("DING!");
        }
  }
C++
  #include <iostream>
  
  class A {
        int x, y;
  public:
         A(int i) { x = i; y = i; }
  };
  
  int main() {
       A *array[16];
       for(int i = 0; i < 16; i++)
               array[i] = new A(i);
        for(int i = 0; i < 1000000000; i++) {
                delete array[i & 15];
                array[i & 15] = new A(i);
        }
        std::cout << "DING!" << std::endl;
  }
If somebody can fix the C# as needed and compare those (benchmarking an optimized build outside the IDE), I'd be much more willing to believe that the results are evidence of MSVC's crappy malloc implementation, rather than just artifacts of other optimizations. Of course, even so, this is still a best (unrealistic) case for GC, since it has to follow almost no data to clean things up. Keeping a few hundred thousand instead of 16 will change it further. (Bottom line: synthetic benchmarks are irrelevant.) Nothings 11:31, 9 April 2006 (UTC)
It's only moderate hyperbole to claim that any program that makes a lot of mostly small (object-sized) allocations/frees will spend less time in heap management under a modern GC than malloc/free. But that's assuming a literal translation of the algorithm. Much subjectiveness in a practical comparison arises because good C++ (as an exemplar language) programmers tend to "instinctively" avoid rapid, small heap allocations and frees. The programming style changes when object allocation is cheap -- so the real reason that direct comparisons are not practically relevant is that you wouldn't write the same program in C# that you would in C++.
That's why the example is meant for conceptual illustration, not as a benchmark or test. Of course, no single, short example can prove anything. So if you feel strongly that the example is more misleading than illustrative, I don't object to blowing the whole section away and replacing it with a vanilla "sometimes it's better and sometimes it's worse" schpeel. It would just be a lot less interesting :-) Mike Lin 18:34, 9 April 2006 (UTC)
I probably will just kill it, then. I was hesitant to do so since you seemed to think there was some substance to the test given the 10-to-1 performance ratio. Actually, I probably could have just fixed things by considering the 'heroic' comment to be NPOV and cleaning that section up, but I think I'll be happier killing the whole thing. It seems excessively detailed in context, anyway. (Much better would be a link off-wikipedia to something demonstrating this, or attempting to.) Nothings 09:20, 10 April 2006 (UTC)
No, I find this makes a valid point. Modern languages really do allocate objects and GC very quickly; much more quickly than malloc/free can, everything else being equal. Malloc in particular has to do a search for object space through the heap, and free is slower too. Malloc has to minimise fragmentation, wheras GC based languages can compact as needed. That makes a heck of a difference. I would expect C## to be much faster in this case.WolfKeeper 03:22, 18 April 2006 (UTC)
(Note to other editors: I deleted the code comparison discussed above and the "can actually be faster (without heroic efforts)" section and replaced it with detailed description of the specific performance issues.)
What you claim isn't true. All else being equal, mallocs are extremely fast in practice. With a well-engineereed malloc (e.g. dlmalloc, the source which is available online), most "searches" for a block pull the block off of a free list in O(1) time. All frees free data in O(1) time (either putting them on a free list, or using a tag-boundary scheme to merge adjacent free blocks in O(1) time). Larger allocations require a search, but with first-fit it's rarely that long and certainly wouldn't happen in the sample code. Also, most garbage-collection languages require some sort of malloc-like fallback for very large allocations. Certainly in the example code case, any reasonable malloc would just keep allocating and freeing the exact same block, which should actually perform better for cacheing reasons than fresh allocations from an advancing pointer in a young generation. (My current guess about the C++ example under MSVC is that it's being screwed up by the fact that the C library allocator asks for larger underlying data blocks from the system heap allocator and sub-allocates from them, and also frees those blocks back to the system if they're unused, so in this trivial test with no other allocations outstanding every new/delete pair triggers the system heapalloc/heapfree calls, which are high overhead (probably require switching to kernel mode). But I don't actually know.)
I understand that lots of people have different opinions on this subject, but WP:V requires more than an opinion or relying on common sense. The code test in particular is seriously flawed. Unless you can produce citations that (a) the code test is valid and that (b) the descriptive section is valid, those sections should be removed. Nothings 06:52, 18 April 2006 (UTC)
I'm generally supportive of the changes Nothings made, although there's probably too much detail both before and after. What would be most helpful would be a general description of the types of allocation workloads under which modern GC is likely to have advantages (and disadvantages), and why. Namely, GC will do better with rapid turnover of lots of small objects due to compaction & contiguous allocation. The example was intended to give this flavor, but obviously any short example can be shot down. --Mike Lin 09:05, 18 April 2006 (UTC)
Øøh! (The reknowned Danish kicked-in-the-stomach sound). Anyone having tried to disassemble the C# and the C++ programs to compare?? Otherwise: use ONE language allowing generational garb as well as manual ungarbed allocation. (Said rursus siderespector the very very anonymous one - lazy fewtime member of the Swedish wikipedia editorhood). (unsigned comment by 83.250.58.54 on 14 April 2006 18:38)

Running on Linux 2.6.15 AMD64, GCC C++ 4.0.3 vs Mono C# 1.1.15 the C++ version is 44% FASTER! I assumed GC is slower so having a concrete examples of increased speed was very interesting, except that it isn't true.

Running on SunOS 5.9 2x1.5GHz SPARC9 GCC C++ 3.2.3 vs the same with the delete removed and using Boehm's Garbage Collector (http://www.hpl.hp.com/personal/Hans_Boehm/gc/), the manual version ran 2.02x SLOWER, reinforcing the original point that in this simple case GC is faster. Gene.thomas 04:04, 22 June 2006 (UTC)

There's a research paper on this subject in the case of Java: http://portal.acm.org/citation.cfm?id=1103845.1094836 --NotQuiteEXPComplete 22:47, 17 August 2006 (UTC)

I have a great idea...rather than playing scientist and constructing trite, easily biased experiments, why don't you look for some existing research papers in this area? Look, there's one in the comment above!--81.86.106.14 11:19, 12 September 2006 (UTC)

There's nothing here that doesn't make sense if you know what's involved in each situation. To break it down, I'll show you exactly why the C# implementation is 18 times faster than the C++ implementation in this case, as well as why it will be even faster in more realistic cases. Firstly, for the C++ case, every time it allocates a new object it must: 1.Look at the free list and find the first available slot. 2.Compare and determine if the slot is greater than or equal to the required size for the object. 3.If not, check the next freelist entry. 4.If so, allocate the object and modify the freelist to reflect the new (and possibly fragmented) memory situation.

  1. 2 and #4 are fairly complex operations since in most cases #1 and 2 will have to be run many times, and #4 often requires new entries in the freelist if the object was stuck into already fragmented memory. In a compacting GC situation such as with C#, when allocating an object it must:

1.Allocate the object at the alloc pointer. 2.Update the pointer to the end of that object.

Neither of these is at all complex, and it's missing MANY of the required steps that C++ must go through. Now, in our little "create a bajillion tiny objects" program, you actually get a fairly good case for manual memory management performance. Every object is released immediately so there's no fragmentation or significant searching of the freelist, and removing an object also doesn't require much modification of the freelist, however the obscene simplicity of alloc in C# vastly outweighs the penalty for the occasional collection whereas in C++ both alloc and dealloc are rather expensive operations (only dealloc is expensive in C#). Again, keep in mind that said program will provide nearly best case performance for the C++ system; in a real program alloc/dealloc is going to create a great deal of fragmentation (unless you go to a LOT of trouble to alloc all ephemerals last) and then the cost of alloc and dealloc grows dramatically as the complexity of the freelist structure increases. With a moving GC like in C#, the performance is more or less dependent on how often it's set to collect, and remains nearly constant in comparison. In fact, worst case for GC is when there ISN'T much garbage to collect. AeoniosHaplo 04:59, 25 May 2007 (UTC)

[edit] Proposed move

I propose this article is moved to Garbage collection and an unequal disambiaguation to waste management is created. —Ruud 02:42, 11 February 2006 (UTC)

It was originally at something stupid like Automatic garbage collection. I would support this move, but I'm afraid that it would emphasise our CS bias. If we had a more quantitative way of establishing how many people are looking for each article, that would help. Deco 03:04, 11 February 2006 (UTC)
I want server logs :) But in absence of those my guess would be that most people looking for garbage collection here will be looking for the CS kind. —Ruud 03:09, 11 February 2006 (UTC)
We could query the hit counts for the two articles in the last database dump. I'll get on it ASAP. Deco 03:26, 11 February 2006 (UTC)
It looks to me like waste management and computer garbage collextion have about the same number of related articles and hits on a search. So I'm guessing the topic are similarly popular, although there is an undoubted CS bias at WP. I vote my CS bias and say, "move it". – Doug Bell talk•contrib 04:51, 11 February 2006 (UTC)
Given that, I'm opposed. It seems an unnecessary move, and with increasing recycling I suspect that garbage collection (waste management) is likely to be ever more important.WolfKeeper 05:24, 11 February 2006 (UTC)
I would agree except that Waste Management seems to be the dominant term in that field, not garbage collection. – Doug Bell talk•contrib 05:37, 11 February 2006 (UTC)
I will have page hit stats from the DB later tonight, if those help at all. Deco 05:40, 11 February 2006 (UTC)
I oppose. I feel the term on its own is sufficiently generic to warrant "(computer science)" for this highly specialized overloading. --Mike Lin 06:30, 11 February 2006 (UTC)
The counts from the page table of the latest dump: since the last reset of the page hit counters, there have been 165 views of Garbage collection, 494 views of Garbage collection (computer science), and zero views of Waste management. This suggests that most of our traffic is coming directly from Google rather than from the dab page, but a fair proportion of people are typing it right in. Nobody seems to care much about waste management, but then the people searching the web are more CS geeks than trash geeks. Deco 21:50, 11 February 2006 (UTC)

[edit] Merging with garbage (computer science)

Perhaps some migration of content might be in order, but the article garbage contains content which doesn't fall under this page. And garbage collection is an important enough topic to warrant its own article. --EngineerScotty 20:57, 11 February 2006 (UTC)

I agree. Many of the topics of the "Garbage" page refer to things unrelated to garbage collection itself. --metromoxie 19:37, 3 April 2006 (EST)
I've re-read the Garbage page twice, and I'm not sure I see which parts are "unrelated" to garbage collection. Could you please be more specific? (I went to the Garbage page looking for some info about uninitialized/undefined/wrong/corrupt values (as in Garbage In, Garbage Out) but there's nothing about that in there.) Ewlyahoocom 18:20, 10 April 2006 (UTC)
It seems to me that "garbage" and "garbage collection" are rather distinct topics. "Garbage" in the usual context is just any piece of data that has no meaning - for instance an uninitialised variable or pointer to nowhere in particular. "Garbage" in the sense of garbage collection, however, is a chunk of memory allocated on the heap that has no references to it - not "unmeaningful" at all, just never-to-be-used. Technically there is no real overlap between these. (In fact they are almost the opposite - the first sense is memory yet to have anything meaningful, and the second is memory which is finished being useful). Keep separate. —EatMyShortz 15:45, 14 May 2006 (UTC)
Oh actually, upon re-reading Garbage, it seems it does deal with both definitions. (I think in my above comment, the GC garbage is "syntactic" garbage and the other is "semantic". Still, this article is specifically about the quite major and important field of Garbage Collection, and the other is about what garbage is. If it is to be merged, it should really be the other way (merge into garbage) - but that's silly because GC certainly needs its own article. So still keep. —EatMyShortz 15:48, 14 May 2006 (UTC)

[edit] Reversible computing

Why is Reversible computing in the see also section? I don't see the connection except in perhaps an esoteric sense. – Doug Bell talk•contrib 21:11, 17 February 2006 (UTC)

There is a deep connection between the two; I forget the exact details off hand, but something like that garbage collection can be implemented using no energy on a reversible computer.WolfKeeper 17:08, 28 February 2006 (UTC)
Maybe because you're not allowed to remove anything since every datum has to be recallable? Wouter Lievens 08:39, 2 June 2006 (UTC)
The reversible model involved being able to undo a sub part of a calculation. So it was something like you could reverse the subcalculation that lead to the garbage being produced without affecting the end result in any way.WolfKeeper 12:06, 2 June 2006 (UTC)

[edit] Performance implication

Well, is the example a good example? Personally, for this kind of program in C++ I would use automatic allocation:

  #include <iostream>
  
  class A {
        int x;
  public:
         A() { x = 0; x++; }
  };
  
  int main() {
        for(int i = 0; i < 1000000000; i++) {
                A a ;
        }
        std::cout << "DING!" << std::endl;
  }

This implementation is probably faster, or at least as fast as the program in C#, and uses less memory than both the C# and the other C++ program! Well, some languages like objective C don't come with garbage collection in their default implementation and cannot perform automatic allocation.

Nicolas (62.147.113.184), June 1st 2006, 23:15 CEST

The point of the original example was to emphasize the lack of a garbage collector in C++ as compared to C#, hence dynamic allocation is necessary as a part of the example... though IMHO the published results are skewed.

[Avi, 2006 June 03, utc - 1801]

I perfectly understand, but at least they could have found an example where dynamic allocation is useful!

Nicolas (62.147.112.212 21:05, 8 June 2006 (UTC))

It's a benchmark. It's not supposed to be useful, it's supposed to stress a particular aspect of a system.WolfKeeper 18:11, 14 June 2006 (UTC)

generational GC ... will place only ... a subset of generations into the initial white set

Maybe into the initial GREY set? -atagunov

Indeed the Nicolas (62.147.113.184), June 1st 2006, 23:15 CEST C++ code is pretty much exactly what modern Java garbage collectors do - adn I'd expect C# would as well. Java (around the hotspot time) talked about short-lived-objects allocated and freed in scopes taht can be recognised by the complier would be just as fast as stack allocations because they basically were stack allocations.

Yeah, the trouble here is getting an accurate example that's also short so we don't lead our readers into some unnecessarily large example. The point being illustrated, I think, is that many GC languages basically automatically pool allocations, which speeds them up versus one-at-a-time allocations (in C++ you can combat this by overriding the default allocator with a custom pooling allocator, but it's not the default behavior). --Delirium 16:52, 22 February 2007 (UTC)

[edit] Criticism

 Please help improve this article or section by expanding it.
Further information might be found on the talk page or at requests for expansion. (June 2007)

I have just added a gentle criticism section, it would probably good to also give external links for known problems with GC (both conceptional or for specfic implementations). However, I didn't want to put too much in at once, maybe a few critical links would help to balance this article. —The preceding unsigned comment was added by 212.209.176.2 (talk) 09:35, 28 March 2007 (UTC).

While the fact that garbage collection implies some overhead is well established in the main article, you're making a number of more worrisome claims without citations. After an hour of searching, I can't find anything more authoritative than questions (not answers) posted in coding forums and mailing lists to support these. Rather than putting in 5 citation needed tags and a weasel word tag, I've removed those statements. Unfortunately this doesn't leave much substance in the section. Please restore it with citations to your sources, I would be very interested in reading them. 67.105.142.34 19:56, 2 April 2007 (UTC)
Hm, I am not happy that the criticism section was radically shortened, on the other hand you are right to ask for more background information. For example see the german wiki article, quote "Eine automatische Speicherbereinigung verringert die Gefahr von Speicherlecks, kann sie aber – entgegen einer weit verbreiteten Ansicht – nicht völlig ausschließen"... translates to: "Garbage collection reduces the risk of memory leaks, but can't - contrary to popular belive - completely remove it". I suggest that someone reasearches the topic, extends the critisim section again and adds more links. Right now, I don't think the article gives a balanced view on the topic. 83.233.56.62 21:32, 3 April 2007 (UTC)
Some links to start with...
http://www-128.ibm.com/developerworks/java/library/j-leaks/ - Handling memory leaks in Java programs
http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html - The Truth About Garbage Collection
http://everything2.com/index.pl?node_id=1048400 - Garbage collection vs. manual memory management
http://portal.acm.org/citation.cfm?id=1094836&dl=GUIDE&coll=GUIDE - Quantifying the performance of garbage collection vs. explicit memory management
http://www.wildcard.demon.co.uk/dev/gc.html - Garbage Collection, 83.233.56.62 22:13, 3 April 2007 (UTC)

[edit] "A form" or "the form"? Garbage collection definition

The definition of "garbage collection" is currently:

In computer science, garbage collection (also known as GC) is a form of automatic memory management.

This definition seems problematic. Is there any form of automatic memory management that is not garbage collection? Cannot garbage collection be about managing other things than memory? -- Lilwik 06:57, 23 April 2007 (UTC)

This objection seems quite correct. The pushdown stack used for recursive procedure calls is another form of automatic memory management, which was not obvious at the time it was invented. Fortran and Cobol did not have that. Garbage collection is memory management for abitrarily linked structures.--Bernard Lang 16:31, 3 August 2007 (UTC)

[edit] Garbage collecting a circular reference

Don't you need some sort of circular reference to really exercise the garbage collector? Isn't garbage collecting a trivial task if you only need to wait until the reference count drops to zero in order to destroy the object? It seems if you are going to exercise the C# garbage collector you should not give it such a straw man.

For example you could have a City class, and a Building class. The City contains X number of Buildings, and each Building points to the City in which it belongs.

Now go ahead and create/destroy 1000000000 City instances in C# and C++ and see which is faster.

198.107.22.21pjc

[edit] Origin of tracing collection

Does anyone know when the concept and the term "tracing collection" was introduced ? --Bernard Lang 17:21, 3 August 2007 (UTC)

[edit] Benefits

The only things mentioned in the benefits section are elimination of certain kinds of bugs. Far more interesting, to my mind, is that garbage collection allows language features that would be nearly impossible to deal with safely absent garbage collection - currying, closures, and so forth. Not sure enough how this should be phrased to make the edit myself. —Preceding unsigned comment added by 141.212.108.138 (talk) 15:17, 2 April 2008 (UTC)

This is an important point - persistent data structures also depend heavily on garbage collection, and it simplifies sharing data across threads. I think the way I would put it is that garbage collection enables features involving memory management that is too complex and error-prone for a programmer to manage on their own. Dcoetzee 15:24, 2 April 2008 (UTC)

[edit] Disadvantages

It would be nice to have a disadvantages section. I'm not really knowledgable enough to add it, but everything has tradeoffs, GC is no exception it seems like this website is talking about that?

http://www.digitalmars.com/d/2.0/garbage.html —Preceding unsigned comment added by Walker9010 (talk • contribs) 05:14, 2 May 2008 (UTC)

Good idea! Visame (talk) 06:31, 8 June 2008 (UTC)