Why other languages don't have automatic garbage collection similar as that of the Java Garbage Collector?

Question

What are the reason/s behind other languages not having a Garbage Collector?

EDIT: Why garbage collection is not built-in for these other languages? why do programmers given the responsibility to collect?

EDIT: All of the questions if possible please :)

Answer 1

A simple fact is that there is no silver bullet. GC does not resolve all memory/performance problems yet.

Answer 2

Some languages are old. For example C, which was originally designed for systems programming on machines much slower than today's. Garbage collection probably didn't exist then (well, maybe Lisp?) and even if it did, the designers wouldn't have wanted to spend all the CPU cycles and memory overhead on garbage collection when the programmers could do it themselves. And since the machines were so much less powerful, software was simpler, and hence it was easier for programmers to manually manage memory than it would be in the much bigger applications which might be written today.

Answer 3

More modern languages like C# and java have Garbage Collection because it's easier to write code if you don't have to worry about memory management. Older languages don't. There are also many applications (e.g. embedded applications running without any access to virtual memory) where you need to manage exactly how much memory your application will use and for these a language like C++ is more appropriate. Real-time applications may also limit your ability to use a garbage-collected language as you need to be in full control of how quickly your application responds at any time.

Answer 4

C, C++, Java and C# were created at different points in time (and in that order). Both Java and C# have garbage collection.

Generally, more recently developed languages tend to have better support for memory management because the state of art has advanced each time.

Answer 5

"Other languages" do - this question is tagged C# and the .NET CLR most definitely does perform automatic garbage collection.

I can think of a few reasons for C++ not to have it:

• All existing code in C++ uses explicit memory management, so implementing garbage collection would be a breaking change;

• By the same token. C++ programmers are already accustomed to explicit memory management, so garbage collection isn't that important a feature;

• Good garbage collection algorithms are fairly new, and C++ predates them by quite a bit. Garbage collection is a horizontal feature and the language designers would have to make major (and complicated) changes to the spec. Put simply, it's harder to bolt on a garbage collector to an existing language than it is to design it into the language from the beginning, as it was with .NET and Java.

• Java runs in a Virtual Machine and .NET uses something similar, whereas C++ deals with native code. GC is much easier to reason about in the former case.

• C++ is often used for applications that need to run under tight memory requirements (i.e. embedded systems), and in these instances, explicit memory management is a necessity. I suppose some sort of "opt-in" GC could solve this, but that is even harder for the language designers to implement properly.

Answer 6

There is actually a GC for C and C++ here.

But in general, the C/C++ communities developed an aversion from day one to learning about many successful programming language features that were widely used in the dynamic language communities, starting with GC. In part, I think this phenomena emerged from the culture of Bell Labs; you had a bunch of hard core hard driving whip smart people who were convinced they knew better and that they didn't need any language features to reduce defect rates. That's why C strings are a nightmarish security hole still creating massive security problems today: because a bunch of Bell Lab hackers knew, just knew, that they could write safe secure code even though the API was made out of razor blades and nitroglycerin. Perfect programmers don't need netstrings and perfect programmers don't need a GC. Too bad that there are no perfect programmers. Confidence is important , but humility keeps us from destroying ourselves.

Answer 7

The hardware has no garbage collector (there was some hardware which had some elementary support for forwarding pointers, a feature useful in the construction of some garbage collectors, but that's far from a "GC in hardware"). Correspondingly, assembly has no GC. Assembly is a "programming language" (albeit one of the closest to the bare metal), so their you go: in the wide spectrum of existing programming languages, some will not have a GC.

It so happens that an efficient GC is not something which is easy to implement. Good algorithms for that have been long in the making. More importantly, most good GC algorithms are good because they perform some elaborate operations such as moving data elements in RAM; this is necessary for the "realtime GC" which offer guarantees on maximum time spent for allocation (you cannot have such guarantees when there is fragmentation, and you cannot avoid fragmentation without moving objects in RAM). When an object is moved, all pointers to that object must be automatically adjusted, which can be done only if the programming language offers strong, unescapable types. For instance, this cannot be done with C or C++. In C, it is legal to print out the bytes which encode a pointer value, and then have the user type them back. The GC cannot change the brain of the user when it moves an object...

So in practice, languages without strong types are GC-less. This includes C, C++, Forth, all kinds of assembly-with-extensions languages... This does not prevent some people to write GC implementations for such languages, e.g. Hans Boehm's GC for C and C++. It does mean, though, that the GC may fail with (weird) programs which are nominally "legal", as far as the language standard is concerned.

There are also languages with strong types but without a GC, either because their designers did not believe in it, or believed they could do better without, or cringed from the extra code size (for instance, Javacard, the Java for smartcards, is GC-less, because fitting a GC in an environment with 8 kB of code and 512 bytes of RAM is not easy).

Finally, among the thousands of programming languages which have been designed ("once per week since the sixties", I was once told), some are the result of late-at-night conversations after too much alcohol, so it cannot be assumed that every feature or non-feature of all programming languages is the result of balanced rational thinking.

Answer 8

If you don't know why, it's because of money. In early days computers were expensive and programmers cheap. Now it's 180 degrees different - computers are cheap and programmers expensive. GC needs a bit of CPU to do his job.

Also, most GC need to make program freeze sometimes to perform full sweep. In a real-time software - industrial monitoring, stock market and so on - this is not an option. And sometimes clients could see it too in one of apps I co-developed (ASP.NET website sometimes froze for a minute or so).

Another reason - nobody's perfect and GC could potentially get some leaks. If you write carefully with some non-GC languages that is not likely.

Answer 9

People already answered to your question, but still, your question has an hidden assertion that is "garbage collection is the solution to all problems", and I would like to discussion this assertion...

GC is not the only way to handle memory

There is at least three ways to handle memory allocation:

• Manually
• Garbage Collection
• RAII

We agree that "Manually" can be actually cumbersome and ugly. Now, you should note that even with a GC, there are some devious ways to leak memory.

GC does not handle resource leaks

There are a lot of limited resources in a program, in addition to memory:

• file handles
• other OS handles
• network connections
• database connections
• etc.

Those are limited resources you want to be freed as soon as they are not used anymore, instead of "not at all" or even "when the process exits".

Those resources must usually be acquired and unacquired manually in GC-powered languages (i.e. Java). If you want to see how ugly it can be, please take a look at this question:

http://stackoverflow.com/questions/194261/raii-in-java-is-resource-disposal-always-so-ugly-was-i-had-a-dream

RAII does handle memory and resource leaks

Using the RAII idiom will enable you to write readable code, without any leaks, memory or otherwise. Fact is, I can't remember a time when, writing C++ code, I was worried by memory allocation/deallocation, despite the fact I use no Garbage Collection.

But I clearly remember that in october 2008, I had to handle a resource leak in Java, and the solution was so ugly it was disgusting.

Conclusion

What are the reason/s behind other languages not having a Garbage Collector?

The answer could be:

• because at that time GC was not effective enough
• because GC is not the solution to all resouce leaks
• because there is no need.

C++ is more in the "there is no need" section.

GC can be a cool bonus to C++'s RAII (see http://stackoverflow.com/questions/228620/garbage-collection-in-c-why ), but there's no way I would exchange my RAII for your GC.

Ever.