If you allocated memory throughout a program, but didn't deallocate it during the program, will the pages used on the heap during the program be free once the program is terminated? How does the operating system handle allocated memory once the program terminates?
Depends on the OS and how it manages memory. Some will completely recover all memory used by a program on termination, and some will not. There are also a couple that attempt recovery of memory used by a program, and don't fully succeed.
As a general rule, if you want to be universally safe, you will ensure that your program releases all resources it uses.
>Depends on the OS and how it manages memory. Some will completely recover all memory used by a program on termination, and some will not.
Could you give an example? As I know when a process is terminated all the resources (including the files) used by that process are released. When a process is removed from process table, the memory it occupies is treated as free.
The OS has a table keeping track of all the running and ready processes. The scheduler decides which process to run next and each time a process is added to ready list, it reorginizes the list according to scheduling policy. On the other hand, the resource manager keeps track of the recources used by each process and when a new process is entered to running state, CPU registers are loaded for this process and the resources it uses are reallocated for it. When a process is terminated, all the resources used by it (files and memory etc..) are freed by the OS. If this was nat the case, we would run out of memory all the times.
If the OS was not free the memory related to terminted process, how would us (even the OS) be able to manage the resource since it has no relation with any process (no entrance in the system tables)?!
MS-DOS is an example of an OS that only attempts to recover memory allocated by applications in some specific circumstances. One of the examples where it doesn't attempt to reclaim memory involved an interaction between a program that dynamically allocated memory from the heap, which was an area of memory managed by some dedicated memory managers.
Unix and windows NT/2000/XP tend to reclaim all resources used by a program as the process terminates. There are some specific examples (usually related to faults in privileged programs or third party device drivers [one reason why, in recent years, Microsoft has sought to encourage vendors to certify programs as "fit for windows"]) where the system sometimes fails to release resources used by a program.
Windows 98/88/Me are examples of operating systems that attempt to reclaim memory allocated by applications but, as those systems sit effectively on top of a version of MS-DOS, they don't always succeed. The 16 bit windows family (eg windows 3.1) also sit on top of MS-DOS, and were notable for not reclaiming memory from some types of application.
With operating systems that do not recover all memory, eventually the system would run out of resources. The symptoms of this would be failure to start programs, or the system complaining about being very low on memory even when few applications are actually running. The OS cannot respond to such conditions effectively: by definition, it incorrectly believes the resources are actually in use by some process or by some part of the operating system. The only solution is to restart the operating system.
There are some dedicated partitioned RTOS's (eg VxWorks for D0178B [D0178B Level A is a set of guidelines for developing safety critical aircraft control systems], and Greenhills Integrity) that offer various guarantees with respect to resources (CPU time, memory, etc) that are made available to a program, and prevent rogue programs from taking down other programs or the OS. They also guarantee reclaiming all resources as programs exit, as a side effect of other guarantees. Those RTOS's are typically a lot more expensive than windows or various flavours of Unix, and are used in safety critical domains.
Last edited by grumpy; 03-13-2006 at 06:35 AM.
