Browse DevX
Sign up for e-mail newsletters from DevX

Tip of the Day
Language: C++
Expertise: Beginner
Jun 26, 2000



Building the Right Environment to Support AI, Machine Learning and Deep Learning

Ruminations on Garbage Collection

Many programmers think of automatic garbage collection (GC) as the Holy Grail of programming that will free them from every conceivable bug. This approach is wrong, though. One has to bear in mind that GC cannot handle every resource that might leak. It takes care of memory and perhaps it can reclaim leaked threads and even close open files. However, many other platform-defined resources still need to be released explicitly by the programmer. Think of a modem. An application that uses it must release it explicitly so that other application can use it; how many garbage collectors are modem-aware? Take another example: a database lock. Here again, you can't expect a garbage collector to close an unused lock automatically.

Put differently, GC is a great tool as long it takes care of reclaiming unused storage. However, when it comes to reclaiming other time-critical or scarce resources, you can't expect a garbage collector to do the job for you; you must release these resources explicitly. When you think of dynamically allocated object as an instance of such resources, then you will soon realize that GC isn't really that useful, after all—it can't replace good programming practice.

Danny Kalev
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date