What is a garbage collector?

Community Forums/General Help/What is a garbage collector?

Yue (Posted 2014) [#1]

I am determined to learn c # and it really has been be an adventure, I do not think I lost time with my unfinished projects in Blitz3D :) but as I read c # has a garbage collector, which is absent in c ++. What is a garbage collector?, And programming in C ++ be more difficult than in C #?

Matty (Posted 2014) [#2]

A garbage collector is really useful. You know how in blitz3d when you create an entity and have to manually keep track of its handle and free it when you are done? - That is different in a system with a garbage collector. With a garbage collector things usually are taken care of in memory when the scope of the function being processed is exited. This means that you don't have to manually go through and "free" entities and the like when you are done with them since they will automatically just magically disappear from memory after your last reference to them in code disappears. Now, some people may initially think they prefer the manual approach like blitz3d but in reality it allows for much cleaner code to do it with garbage collection.

dynaman (Posted 2014) [#3]

It does allow for cleaner code BUT if is is badly implemented it also causes stutters at the worst moments. There are ways around that however and most modern implementations do not cause the stuttering problem.

* (Posted 2014) [#4]

I was gonna say a person who empties ya bins lol Its just a part of the language that checks for unreferenced data in your program and then gets rid of it, for example a loaded texture that isn't linked to a code texture reference would be a prime candidate. It runs every so often and cleans up the useless data.

Yasha (Posted 2014) [#5]

One thing that's interesting about a garbage collector is that, contrary to what you might assume, with all the extra code and stuff going on in the background, a well-implemented one (like the ones used by Java and C#) actually results in faster code overall than manual deallocation. There are some complex reasons for this, but it basically comes down to the allocator being able to make more effective use of the memory it's given, when it has more information about the objects. (Another fun counterintuitive fact: some GCs, like GHC's generational collector, actually get faster the more garbage your program produces!) Unfortunately the faster the collector, the more likely it is to "stutter". At the moment, the main tradeoff in memory handling is that you can have a completely pause-free and smooth program, or you can have a program that pauses occasionally, but runs faster overall. (Although a well-designed program on modern hardware will often only have pauses of 1 or 2 ms, which is good enough for gaming these days.) On a technical note, there are also two meanings of "garbage collector" in current use. The posts above are the definition used by most programmers - any system that automatically cleans up memory for you without needing to write it into the code. But in "the literature", garbage collection normally specifically refers to tracing collectors, and doesn't cover other automatic memory management strategies (of which there are several). BlitzMax uses a refcounting collector, so many outsiders would actually say it has no GC. (Apple's ARC uses a very similar collector and they are really adamant that it should not be called a GC, mainly for marketing reasons.) Other collectors include region-based and type-based collectors. They all have different general performance and coding implications (types = fastest but hardest to code for; refcounting = slowest but easiest to code for). The main disadvantage of garbage collectors is that they use a lot of memory, which is why Apple likes to discourage the idea of them on mobile devices which have little memory. (I think the best tracing GCs at the moment only outperform manual management when they can use at least ~170% of the memory for the same program; many will use more like 500% if they can get away with it.)