Re: physical memory allocated to a program
- From: phil-news-nospam@xxxxxxxx
- Date: 29 Mar 2008 13:21:56 GMT
On Fri, 28 Mar 2008 02:59:22 -0700 (PDT) mohi <mohangupta13@xxxxxxxxx> wrote:
| presently i was reading about physical memory allocators and wanted
| to know ,as the size entry of the program( the size of the program in
| directory entry) includes the size of the code of the program and not
| that of the dynamic memory which that program may require(as i
| think) ,so how does the kernel or the allocater decides what block of
| memory should be actually allocated to the program(which will also
| include the dynamic memory which may be required by the program beside
| the memory required for its code.
There kernel has basically two ways it can add memory to an instance of
virtual memory. It can map an object into the memory, or it can extend
the end of the data segment. When the kernel executes a new program image
it maps that image into memory along with a dynamic linked if needed (it
usually needs it). The dynamic linker then maps in other libraries as
needed. The process may map in other files as well. There is also a way
to map in anonymous memory not backed by a real file. The brk() system
call is a classical way to extend memory in place. See the man page on
the mmap() and brk() syscalls for more info. Also see shmat().
Calls to malloc() just invoke user space library code to manage memory in
the VM, and allocate pieces of it in finer increments. It calls mmap() or
whatever else a given kernel provides to get "wholesale" chunks of memory.
Some programs operate on a garbage collection basis which manages memory
in a different way. In theory, you could write a program that makes no
use of any sort of management of the memory in a process, and just do it
all on your own however you like, within the confines of syscalls. The
only time I would consider it worthwhile to write such a program is in a
systems programming class just to experience what the syscalls do. Real
world apps should use the normal, or if needed, a specialized, allocator
function/library.
Your question focuses on size. It is the size of the file that matters
in the initial mapping. Thereafter, the kernel maps files in whatever
amount the mmap() syscall to it says to. It can map portions of a file
(a critical ability for files of GB sizes on a 32-bit system). If not
enough memory is available, the calls fail and return error codes. That
may result in the program choosing to abort its execution (such as the
malloc() library call returning NULL and the program outputting the "out
of memory" message and aborting).
The mmap() call can map to where the caller specifies, or it can let the
kernel choose where. I don't know the details of how it decides. You can
read the kernel source code to find out, like I would if I became curious
enough to do so.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-03-29-0758@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- References:
- physical memory allocated to a program
- From: mohi
- physical memory allocated to a program
- Prev by Date: Re: physical memory allocated to a program
- Next by Date: Re: pci memory access in user mode?
- Previous by thread: Re: physical memory allocated to a program
- Next by thread: pci memory access in user mode?
- Index(es):
Relevant Pages
|
