“simulating a computer with an infinite amount of memory”

Thanks to this article by Raymond Chen we can read what garbage collection really is and (perhaps even more valuable) what it is not.

I don’t want to start a new flame war about garbage collection (and even when – hey, this is my blog!), but I for myself I’m glad that Delphi doesn’t offer such a feature. We are always tempted, aren’t we?

Not that I don’t have any memory leaks in my programs. Not that I don’t use memory already freed. But with the right tools you can actually spot those errors and solve them. Doing so I often find some other error lurking in my code, just waiting to pop up like a jack-in-the-box. If there were no more such leak hunting, I would know less about my code than I do now.

Delphi doesn’t lack garbage collection – Delphi doesn’t need one.

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's

6 thoughts on ““simulating a computer with an infinite amount of memory””

  1. Incompetent (and/or careless and/or lazy) programmers do need garbage collection. That’s why it has been a design requirement of Java and .Net.

    But then it’s not even a panacea, as they can still leak other resources or hog memory by keeping references they don’t need anymore.


    People complain about the lack of GC in Delphi most often claiming that having it would alleviate the tedium of having to litter their code with try..finally.

    They don’t understand that it would do no such thing; that try..finally is still needed and that arguably MORE discipline is required, not less. Currently you don’t need to really think about memory management and finalization, you simply have to remember to always do it, where-as with a GC issues actually become MORE complex (due to greater variation in need depending on what resources you are working with).

    The one thing this tells me is that the people who wish they had GC are the last people who should be allowed to have it because they simply don’t understand what it means.

    They also don’t understand that they can address (remove) the need for try/finally with just a very small amount of work on their part themselves, taking advantage of what Delphi already offers, rather than whinging about what it does NOT offer.

    The link above is a reference to my blog post about an implementation of “AutoFree” to exploit the managed lifetime of interfaces to provide automatic scope-cleanup of objects: http://www.deltics.co.nz/blog/?p=391

  3. I strongly agree. There is a lot of really bad code out there due to design that is sloppy and assuming an infinite amount of memory. I wrote a database application using MS SQLServer which pushed it to it’s limits. I could crash the SQLServer 10 times a day due to it leaking memory due to MS sloppy code. The project still needed to be completed, so I wrote my own database engine in Delphi. It simply doesn’t leak memory and it runs for years without a reboot. The extra bonus was that it also runs 100+ times faster and can run via a single executable on 1/10 the memory. The real bonus was gained in learning to performance tweak every routine and think ahead and look at the big picture when programming. I have been a Delphi programmer since version 1 and will continue as long as they keep producing versions.

  4. I like my Delphi programs to be leak free, bounded in their memory use, and bounded (within reason) in their performance. I find that it becomes harder and not easier to establish these bounds, and test my application, when I add a large pile of mystery meat into the middle of it. This mystery meat offers me the promise of no-more-memory leaks, but can not promise that I won’t run into a GC cycle when it’s not exactly opportune. Apps which don’t get hurt by running non-native code (because frankly, they don’t do much processing anyways), and which use a trivial amount of data (typical database CRUD screen apps) at a time, don’t need, and aren’t harmed by GC. But adding GC limits what else you can do. GC is not like an automatic transmission in a car. It’s like wearing a rubber suit you can’t take off.


  5. I remember when computers had only 64k ram and we had GEOS… no one needed a GC in that times, why we need it now? Something new programmers need to learn is about efficency, in nowdays they are very lazy and relaxed. This is a bad concecuence of having nearly unlimited resources in modern computers. Having limits pushed us to be efficient, to think really well and to make deep planning before programming. A rule of thumb, measure twice cut once.

Comments are closed.