Garbage Collection - Why?

[Oria]

I dislike garbage collection because it basically circumvents scope-based object lifetime when it really shouldn't

That depends. Now I'm not sure about Java, but in C# you have a way to do that. Structs are value type objects which go on the stack and get destroyed when you go out of scope, while classes go on the heap. So a properly designed software would make use of structs for all small meaningless objects.

[rapidcoder]

I dislike garbage collection because it basically circumvents scope-based object lifetime when it really shouldn't

There is nothing in GC per se, that'd circumvent that. It is just that in GCed languages the need for scoped-based object lifetime is not that prevalent.

E.g. in Scala I can implement C++ RAII with structural typing, lambdas and finally, as a separate method. This could be used like that:

doWithRAII(new SomeObjectWithDestroyMethod()) { obj =>
  // method body in many lines
}  // tada, here the destructor destroy() will be called automatically for you, even in case of an exception 

[Cheraphy]

Languages are a tool. Good tools are useful and easy to use. Various features of a language effect how useful or easy to use it is. If something is introduced that makes it easier without effecting it's usefulness, then why not embrace that as a standard? In this case the usefulness is measured in speed. The impact of garbage collection can be made completely trivial by assigning it's thread to a dedicated CPU core in a multi core system. As multiple cores become cheaper (and more plentiful) the more likely it is that the GC's impact on the speed of the program's execution will be trivial. So, why wouldn't it be a natural progression for languages and engineers to embrace such a feature?

edit: fixed grammar and added clarity.

[Telion]

You would give up a whole core just for resource cleanup? You must not be doing very much computation on your other cores if you think that is a good idea.

[chrisname]

That's entirely dependent on how many cores there are. On a modern PC which only has 6 at a maximum, no, but if I had like 100 cores then I think dedicating one to GC would be okay. Especially if it was GC at the OS level - no process would have its own GC, there'd just be one for the entire system, running constantly on its own core. I've been interested in how well GC at the kernel level would work for a while.

[cire]

Of course, it's probably good to remember that C++ is used in many environments where resources are constrained and/or where deterministic behavior is required.

[edit: exchanged "restricted" for "constrained"]

[Cheraphy]

Alright, it doesn't have to be dedicated.

[greenleaf800073]

What is this thread about?

[firedraco]

People arguing over why the garbage dumpsters come every week.

[LB]

I would be pissed off if random garbage dumpsters were just plopped on my front lawn every week.

[Catfish3]

I would be pissed if I had to drive the garbage truck myself.

[rapidcoder]

Of course, it's probably good to remember that C++ is used in many environments where resources are constrained and/or where deterministic behavior is required.

Java is used in those applications, too. And it is a GCed language. Why is it possible? Because there are a few implementations of real-time GCs out there. E.g. some smart cards are a resource constrained / embedded environment, and they are programmed in Java.

C++ dynamic memory management is not any more deterministic than GC.
This is not a problem of GC vs non-GC, this is a matter of implementation only. The standard popular implementations of memory allocators used in popular C++ runtimes are not deterministic and don't guarantee any maximum levels of fragmentation. Neither deterministic is STL. So C++ offers by default just the same what Java offers with GCs - most of the time it works fine, until it suddenly freezes and you can't do anything about it.

[LB]

@Catfish3 I was showing that firedraco said the wrong thing, I wasn't complaining about garbage collection in that specific post.

[cire]

C++ dynamic memory management is not any more deterministic than GC

C++ doesn't require the use of dynamic memory, and it is certainly far easier to make dynamic memory management in C++ deterministic currently, than it would be with GC.

[Catfish3]

rapidcoder wrote:

Neither deterministic is STL.

Could you elaborate on that, because I have no idea what you mean...

[tition]

C++ dynamic memory management is not any more deterministic than GC

Conversely, GC is no more than a glorified* non-necessarily bulky, non-modular, dynamic memory manager.

*glorified by the worshipers of Java, not because it is particularly good.

[Disch]

That's simply not true, tition.

[tition]

@ Disch:
elaborate please, both on the technical side and on the conceptual.

I think I would have no problem writing (using an eventually restricted subset of c++) a program in which all pointer locations are accounted for and modified should the need arise. I am only not sure how to exactly handle the pointers located on the stack (most notably, the this pointer).
[Edit:] That shouldn't be a big problem either.
but if that becomes that much of a problem, I would just forbid non-static function calls.

[Disch]

GC has lots of practical applications. rapidcoder has already brought up its uses in functional languages, and how it makes some techniques possible that otherwise would be impractical. It also offers a solution to other problems with traditional memory management, as have also been listed throughout this thread.

Whether or not GC is "bulky" depends on the implementation, and the needs of the program.

Though I'm not going to get more into specifics, as I feel I've spent enough energy on this reply as it is. Your stab at Java "worshipers" (and your overall tone in that reply) just looks like hateboyism to me _{(I just made that term up... it's like fanboyism but where you have an irrational hate of something rather than an irrational love of something).}

Like anything else in programming, it has its tradeoffs. There are times to use it and times to not use it. Only a fool throws aside tools as useless just because he doesn't understand the uses for them.


EDIT:

Besides.... I shouldn't have to elaborate anyway. You're the one who's making the claim here. Why don't you elaborate and/or back up your claim?

[tition]

Besides.... I shouldn't have to elaborate anyway. You're the one who's making the claim here. Why don't you elaborate and/or back up your claim?

Fair enough. I admit I was trolling.

Like anything else in programming, it has its tradeoffs. There are times to use it and times to not use it. Only a fool throws aside tools as useless just because he doesn't understand the uses for them.

I completely agree with you here.