Memory free when program exit

[tiesun]

Hi:
I have doubt by the two articles.
One said the system won't reclaim the memory resource when the program exit . One said it would do . so which one is right?
or they are both right because they are talking about differnt OS platform?

Article One:
http://www.howstuffworks.com/question466.htm
When any program begins running, it uses up some space in the "system resources" area in memory. But, as you exit, some programs do not give back system resources they were temporarily using. Eventually the system will crash as it runs out of memory. The crash happens sometimes if you start and close many programs, even the same ones, without a periodic reboot. This is what Microsoft calls a resource leak or memory leak.


Article Two:
www.hpl.hp.com/personal/Hans_Boehm/gc/myths.ps (http://)
Allocation Myth 4:Non-garbage-collected programs should always deallocate all memory they allocate. The Truth:Omitted deallocations in frequently executed code cause growing leaks. They are rarely acceptable. but Programs that retain most allocated memory until program exit often perform better without any intervening deallocation. Malloc is much easier to implement if there is no free.

In most cases, deallocating memory just before program exit is pointless. The OS will reclaim it anyway. Free will touch and page in the dead objects; the OS won't.

Consequence: Be careful with "leak detectors" that count allocations. Some "leaks" are good!

Best Regards

[PaulWendt]

TECHNICALLY, a programmer shouldn't rely on the OS to do any-
thing. The OS isn't required to reclaim lost memory in this fashion.

In practice, however, from what I understand, at least the NT
versions of Windows do reclaim memory to the best of their
ability. Most modern operating systems do -- including most
flavors of unix -- from what I remember. I think [but I could be
wrong] that the Windows9x/ME OS's don't have this improved
memory cleanup strategy and will allow leaks a lot more readily.

I think it's a very poor practice to use malloc/new without calling
free/delete. If the memory's going to get reclaimed anyway as
the article claims, what harm can there be from explicitly
deallocating when you need to? There's no such thing as a free
lunch and if memory's going to be deallocated, it'll have to be
deallocated when the program's completed too in their argument.
Maybe if the OS "reclaims" memory faster than free does then
you'll see increased performance; this technique won't help you
with any program that must remain running for any long period of
time, however, so I'd recommend you use free/delete.

--Paul

[jwbarton]

The first article that you referenced is specifically addressing resource leaks in Microsoft Windows. When you use various resources in Windows 95/98, the resources are allocated from a small memory pool (two 64K areas). Since this is a very small area, it can quickly be filled. In addition, if a program doesn't free these resources, these earlier versions of Windows will not automatically free them upon exit. This results in the system giving "out of memory" errors. The error is due to this small pool running out of space, not due to the total system memory being exhausted.

More recent versions of Windows have mostly fixed the problems with resources, as the small pool is not handled the same way. It still is important to free resources when you no longer need them, but you won't see the same "out of memory" errors if you are using Windows 2000/XP.

The second article (which I couldn't link to) is referring to the address space allocated to the program for its running space. This includes normal malloc/new style allocations. It is not referring to resources allocated from the special small pool. For all versions of Windows that I am aware of, the memory allocated by a program for its normal running space is freed back to the operating system when the program exits. However, it is generally a bad decision to leave this up to the operating system to clean up at program exit.

Best regards,
John

[Paul McKenzie]

I know that MSDOS does not reclaim memory, so neither will Windows 3.x.

If you don't properly use delete or free(), or properly free up resource handles, the problem will come when one of these scenarios occur:

a) You move the code that is leaking into another module. This new module is now called repeatedly throughout the program. Your program dies very quickly due to the memory leak.

b) If you don't move the code, a client now runs your program for 24 hours straight. Your program dies after 18 hours due to a growing memory leak. Similarly, a customer wants to process a 50,000 page document. Your program dies on page 20,000 due to the memory leak.

a) and b) are similar -- you never know when, where, or how the "leaking" code will be exercised -- either now or in a future version of your program.

Hans Boehm created a memory garbage collection module. His goal is to make others use the garbage collector, which gives me the feeling why he's claiming that not freeing memory is a good thing. The only way to not get into trouble deallocating memory is to use a garbage collector, and his is one of the best one's out there.

I have all the respect for Hans, but if you are not using a garbage collector, you better fix any leak that can be fixed and not rely on the operating system. You never know when the OS cannot help you, and the scenarios outlined above are those cases.

Regards,

Paul McKenzie

[Gabriel Fleseriu]

A personal oppinion about garbage collectors:
Apart from the technical aspects, I think they also have a psychological aspect. They seduce the programmer to follow the phylosophy "It's OK to make a mess, there is somebody cleaning up after me.". And that, in general, is a bad practise. There are situations where garbage collectors are dead-usefull, as there are situations in life where you are allowed to make a mess without thinking of whom's going to clean up. But if it's your habit to make a mess and not to clean up, sooner or later this will turn against you. In real life and in programming.
My two cts.

[Graham]

... and there's more to resource management than memory.

If a garbage collector encourages language writers to dispense with deterministic destructors (a la C#, Java), then let's ban garbage collection. What bugs me is when the system forces a GC on you and calls anything you do with manually managed resources "unsafe" - loaded language, or what?

Interesting article in CUJ this month about using "managed" code with STL containers (it's a problem...). The solution appears to be to wrap your "managed" pointer in a class called gcroot. Inspection of this class reveals something interesting. Once you strip out the constructors, assignment operators and type conversion operators (all designed to make the class more-or-less transparent in use), you are left with one member function. Want to guess what it is? Yep, a deterministic destructor. "Managed" code, despite the hype, is useless in a std::vector, or a std::list, or a deque, a map...... unless you put the deterministic destructor back. And, no, that doesn't reflect badly on the STL containers, it reflects badly on "managed" code.

[AnthonyMai]

TECHNICALLY, a programmer shouldn't rely on the OS to do anything. The OS isn't required to reclaim lost memory in this fashion.


Technically, the OS, shouldn't expect a program to do any thing. The OS can not expect the program to be correct. It surely can not assume the programs are bug free. And it has to be prepared to deal with page fault, access violation or other situations where the program must be terminated forcefully and immediately, without letting it run through its full life.

So it is only logical for an OS to always reclaim memory used by a process upon process termination, regardless whether the program itself does it or not. But certainly there is not a OS standard, so any behavior is possible.

From a programmer point of view, it is best to make as few assumptions as possible about the system you work on. You should base your code on clearly known facts, not on sometime you presume to be.

For example, do not assume you can use 4 for size of an integer, instead use sizeof(int). Do not assume the first byte of a 4 byte integer is the lowest byte: it could be a big endian system. Do not assume a C++ template can be instantiated for any data type: you can calculate the modulo of one integer against another integer and the result is a modulo, but you can't do the same for floats, and surely you can not multiple a string with a string like you do with integer multiplications. Generic codes doesn't work and they are error prone. It's best to not to make any assumptions at all about the system or the data you are dealing with.

I like the idea of symmetric code. If you allocate memory. you have got to de-allocate it. If you create an object, you have to destroy it. If you write a initialization function, you must write a clean up function, right next to it, shoulder-to-shoulder. If you write something converting an int to a string, you must immediately creating something that does the opposite conversion and put right next to it.

And when you are done with every thing, Do a global search to see if the count of occurance of "malloc" and the count of "free", equal to each other. And count how many times "new" occured and how many times "delete" occured. The number must match if you have done things in a symmetric way. A mismatches number tells you right away that you have forgotten something.

And it also helps to put comment on where you allocate/deallocate memory, to indicate where the corresponding deallocate/allocate sits.

The simplicity is in the symmetricity. The beauty is in the symmetricity. And the truth is in the symmetricity :-)

[Amn]

Originally posted by Gabriel Fleseriu
A personal oppinion about garbage collectors:
Apart from the technical aspects, I think they also have a psychological aspect. They seduce the programmer to follow the phylosophy "It's OK to make a mess, there is somebody cleaning up after me.". And that, in general, is a bad practise. There are situations where garbage collectors are dead-usefull, as there are situations in life where you are allowed to make a mess without thinking of whom's going to clean up. But if it's your habit to make a mess and not to clean up, sooner or later this will turn against you. In real life and in programming.
My two cts.

Dont think so at all. We are entering new era of programming when we choose whether to trust third parties or not. Having quite a history with failing software in the past, of course every skilled programmer will teach newbies oldskool, but it only is half-good - you teach them to be cautious but you also teach the the DOS way of programming. I have been coding since 12 and personally dead tired of the same memory freeing routines....

I believe garbage collecting is a very efficient mechanism...And no i didn't get lazy after i began using it, and i am using my prescious time more efficiently having more of it to do other tasks ;)

Be carefull gurues, when teaching newbies ....software design evolves too, it eveolves with us