views:

411

answers:

4

When talking about a process' memory, I heard about things like code memory and data memory.

And for the data memory, there are 2 major managing mechanisms, stack and heap.

I am now wondering how is the code memory managed? And who manages it?

Pardon me if my statement is not so clear.

Thanks.

+2  A: 

It is managed by the operation system. When a program is run, it's code is loaded from an executable file to some memory address. Depending on the nature of the program, some changes are applied to the code sections, e.g. jumps to dynamically linked libraries are resolved.

As proposed by Space_C0wb0y, check out en.wikipedia.org/wiki/Dynamic_linker for details on what is going on.

inflagranti
Check this wikipedia-article about dynamic loading for some insight in to what is going on: http://en.wikipedia.org/wiki/Dynamic_linker
Space_C0wb0y
Thanks Space_C0wb0y, that link is helpful.
smwikipedia
+16  A: 

I recommend http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory (and the other memory related articles) if you're interested in finding out more about the details of process' memory management.

code memory = Text segment

Notice how the address space is 4GB. When the kernel creates a process it gives it virtual memory. Below is an example of a 32 bit OS. The kernel manages what addresses get mapped to actual RAM via the processor's MMU. So, the kernel and the MMU manage code memory, just as they manage the entire address space of a process.

Borrowed from duartes.org

TheJuice
very nice link...
wrapperm
I second wrapperm. :)
smwikipedia
The layout is generally set (and managed) by the linker rather than the kernel. The kernel just reads the info in the executable image and sets up the memory map accordingly. The dynamic linker will get mapped in if the executable so specifies (which is does for dynamically linked executables) and handles a lot of things. You may consider the linker 'part of' the OS, but you could create a custom linker that does just about anything you want,
Chris Dodd
thanks for the article link.
Gollum
Please be extra sure to note, that the graphic does NOT represent the default state for applications in windows.In windows the Kernal by default takes 2 GB's, leaving the app with 2 GB's of user mode memory. So this graphic makes a lot of assumptions.To get the 3 GB's of user mode, you have to set the '3 GB switch', and you have to link your app with the LARGEADDRESSAWARE switch. I'm just pulling those names out of my memory, so you will have to google those terms to get more specifics. The other assumption about this graphic is that you are using a 32 Bit OS.
C Johnson
A: 

Your operating system provides so called system calls to dynamically allocate memory (malloc, free, etc.), it also provides the mechanism to load and execute your program.

When the program is loaded by the os the text segment (code memory) is set up and the statically allocated memory in your program is immediately available. As your code calls functions, the (statically allocated) variables in your functions are allocated on the stack and your dynamically allocated memory (using malloc() for example) is allocated on the heap. During the time your program runs, it is your (the programmer's) responsibility to manage the memory (lack of doing so will lead to memory leaks and will eventually cause a long running program to run out of memory and it will crash, or in extreme cases, depending on the OS, take the whole OS down with it).

See also this article: http://www.maxi-pedia.com/what+is+heap+and+stack

Marc van Kempen
The heap is not managed by the kernel on most operating systems. It is usually a purely user-mode component residing in some kind of runtime library (e.g. ntdll, libc) which then makes system calls to lower-level page-handling functions (e.g. NtAllocateVirtualMemory).
wj32
+3  A: 

The code memory doesn't need managing because it doesn't change. When an executable is loaded into the address space, the code is just read from the executable file into memory. In fact, on modern operating systems, the code segment is just memory mapped to the executable file.

JeremyP
Well, well.... it depends on operating system. As I remember from A. Silberschatz book on operating systems, some architectures may be able to move the code, but it must be transparent to the programmer. Also loading/unloading dynamic libraries involves some memory management of the code.
doc
@doc: True, but it varies between OS and architecture. What I said above is based mostly on poking about with the OS X executable file format.
JeremyP