Talk:Garbage collection (computer science)

Neutral point of View?.

Some of the disadvantages do seem to be a bit biased... For example "Memory may leak despite the presence of a garbage collector".... Saying this is a disadvantage, is like saying a boat might sink despite the presence of a sealed hull... Even a manually memory managed environment, logical memory leaks can exist if care is not taken to correctly track objects to identify when they are eligible to be deallocated, or indeed end up as potential sources of memory corruption if the object is deallocated too soon.... "Programs that rely on Garbage Collectors" bullet, doesn't identify GC as been a problem, but instead programs that use GC, also tend to have other problems not related to GC. — Preceding unsigned comment added by 62.189.160.66 (talk) 13:51, 11 July 2011 (UTC)

I agree with your second statement. The problems pointed out seem too much of a stretch. I've removed the paragraph. Perhaps it would be interesting to understand what this sentence even meant. It seems to imply GC causes major layout changes in data... which does not make much sense.

I disagree with your first statement. The whole point is that you can have problems even if you play by the rules. Or at least, this is what I get out of it. I still not quite understand how this is supposed to happen, perhaps a citation needed would be appropriate.

MaxDZ8 talk 14:44, 22 August 2011 (UTC)

I think the RAII stuff is not just a matter of neutrality, but also of relevance. The (irritatingly) implicit claim is that RAII solves a more general problem than automatic memory management. However, no supporting evidence or links are given. The counter-arguments (that memory is not a "resource" in the same sense as a file handle because its behavior is not essential to the behavior of the program as a whole, and that because of this, memory can be abstracted fully and other "resources" cannot; that many languages include syntax or macros for this situation, eg "using" in C# and dynamic-wind in Scheme, unwind-protect in Common Lisp; that there are sophisticated (far moreso than RAII) means of reifying time and IO interactions that actually rely on GC, such as functional reactive programming) are also not addressed or mentioned. Instead we have extremely C++-myopic claims of RAII's superiority and distinguishing between "pointers" and "references", which I assume are referring to the C++ concepts (as if they were essential and relevant outside of C++.)

And that touches on another issue that I have with this article: it doesn't mention automatic memory management's central role with respect to functional-style programming, persistent data structures, and avoiding mutation, and the parts about the disadvantages are written from the perspective of a highly state-ful point of view. The parts of this article that mention RAII seem like they're totally missing the point. It's not that it's POV, it's that it's uninformed and C++-myopic, rather like saying an M16's lack of a bowstring is a flaw.

In order for it to continue in its current state, the implicit claim mentioned above should be made explicit and citations should be provided. Otherwise, I'll remove the parts that rely on it or that I judge as C++-myopic. I may also write a bit on automatic memory management's intimate relationship with functional programming, though I would prefer if there was a separate automatic memory management article and that this one stuck to things more specific to GC algorithms (as opposed to, say, reference-counting.) Cengelhard (talk) 21:10, 5 January 2012 (UTC)

There is no such claim either implicit or explicit. The disadvantage simply states that non deterministic garbage collection of only part of the resources effectively disables RAII based resource management of the remaining resources, and it simply illustrates the potential impact of this fact by focusing on the transitiveness for composition in the 'close' example. Simply stated, if you manage all you resources with GC or manage all your resources with RAII there is no such problem. If you manage part of your resources with deterministic GC (for example reference counted GC as in as the RAII page states c-Python) and the remaining resources with RAII there is no such problem. Only when you manage part of your resources with non deterministic GC than the rest of your resources fall outside of the scope of your GC, than these resources won't be managable with RAII either and will require alternative resource management at each level of composition. Please lets try to keep stuff objective here.I understand your dislike of C++, C++ is a hard to like language with many bad parts, but we must be objective about the fact that RAII is a completely valid alternative for GC that has very interesting compositional properties. You apparently don't like C++ and probably for this reason don't like RAII but please lets keep this page objective and be fair about the fact that its partial incompatibility with RAII can be seen as a disadvantages to some forms of GC especially given these compositional properties. Please read the "Disadvantages of scope bound resource management alternatives" of the page on RAII, hopefully that should give some perspective on why the inability to use RAII for 'remaining' resources is indeed something that can be seen as a disadvantage.

"semantic" versus "syntactic" garbage: poor terminology

The article uses the term syntactic garbage in reference to objects which are actually not reachable through the transitive closure of live references. This is a poor term, because this reachability very much has to do with the semantics of what computation has occured until now. Only in trivial examples is this linked to the syntactic structure of the program. If garbage was syntactic, it could be statically analyzed without the need for a tracing garbage collector! Note that any language which is compiled and designed for garbage collection from the ground up, the compiler can help the garbage collector. If a variable has no next use in a block of code (as determined by the compiler's data flow analysis), then that variable need not be considered as a source of live references for GC. The compiler can emit information so that no matter what execution point in the code triggers GC, the information about variable liveness in that scope is accurate. So it is not true what the article claims: that an object can become syntactic garbage long before it goes out of scope. That is precisely what liveness analysis is for. This is a problem of a poorly integrated garbage collector (e.g. a bolt-on GC library for C programs which blindly scans the stack.)192.139.122.42 (talk) 23:43, 2 November 2011 (UTC)

Disadvantage: You can't have pointers, only references.

What exactly does this mean? Isn't the reference vs. pointer distinction a C++ism? Java certainly allows Null..uh, references, for instance, and things like the Boehm GC for C exists. Surely C has pointers? Ketil (talk) 13:59, 17 January 2012 (UTC)

Also, although it's not clear from the article, I'm fairly sure a modern GC doesn't have to touch the garbage, i.e. that it's running time will be proportional to the live heap only. This is a potential performance advantage over manual memory management, which requires the user to free every allocated object. Ketil (talk) 14:07, 17 January 2012 (UTC)