13

I am not clear with memory management when a process is in execution during run time

Here is a diagram enter image description here

I am not clear with the following in the image:

  • 1) What is the stack which this image is referring to?
  • 2) What is memory mapping segment which is referring to file mappings?
  • 3) What does the heap have to do with a process. Is the heap only handled in a process or is the heap something maintained by the operating system kernel and then memory space is allocated by malloc (using the heap) when ever a user space application invokes this?

The article mentions http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/

virtual address space, which in 32-bit mode is always a 4GB block of memory addresses. These virtual addresses are mapped to physical memory by page tables,

  • 4) Does this mean that at a time only one program runs in memory occupying entire 4 GB of RAM?

The same article also mentions

Linux randomizes the stack, memory mapping segment, and heap by adding offsets to their starting addresses. Unfortunately the 32-bit address space is pretty tight, leaving little room for randomization and hampering its effectiveness.

  • 5) Is it referring to randomizing the stack within a process or is it referring to something which is left after counting the space of all the processes?
Alex DiCarlo
  • 4,851
  • 18
  • 34
Registered User
  • 5,173
  • 16
  • 47
  • 73

3 Answers3

11

1) What is the stack which this image is referring to?

The stack is for allocating local variables and function call frames (which include things like function parameters, where to return after the function has called, etc.).

2) What is memory mapping segment which is referring to file mappings?

Memory mapping segment holds linked libraries. It also is where mmap calls are allocated. In general, a memory mapped file is simply a region of memory backed by a file.

3) What does the heap have to do with a process. Is the heap only handled in a process or is the heap something maintained by the operating system kernel and then memory space is allocated by malloc (using the heap) when ever a user space application invokes this?

The heap is process specific, and is managed by the process itself, however it must request memory from the OS to begin with (and as needed). You are correct, this is typically where malloc calls are allocated. However, most malloc implementations make use of mmap to request chunks of memory, so there is really less of a distinction between heap and the memory mapping segment. Really, the heap could be considered part of the memory mapped segment.

4) Does this mean that at a time only one program runs in memory occupying entire 4 GB of RAM?

No, that means the amount of addressable memory available to the program is limited to 4 GB of RAM, what is actually contained in memory at any given time is dependent on how the OS allocated physical memory, and is beyond the scope of this question.

5) Is it referring to randomizing the stack within a process or is it referring to something which is left after counting the space of all the processes?

I've never seen anything that suggests 4gb of space "hampers" the effectiveness of memory allocation strategies used by the OS. Additionally, as @Jason notes, the locations of the stack, memory mapped segment, and heap are randomized "to prevent predictable security exploits, or at least make them a lot harder than if every process the OS managed had each portion of the executable in the exact same virtual memory location." To be specific, the OS is randomizing the virtual addresses for the stack, memory mapped region, and heap. On that note, everything the process sees is a virtual address, which is then mapped to a physical address in memory, depending on where the specific page is located. More information about the mapping between virtual and physical addresses can be found here.

This wikipedia article on paging is a good starting point for learning how the OS manages memory between processes, and is a good resource to read up on for answering questions 4 and 5. In short, memory is allocated in pages to processes, and these pages either exist in main memory, or have been "paged out" to the disk. When a memory address is requested by a process, it will move the page from the disk to main memory, replacing another page if needed. There are various page replacement strategies that are used and I refer you to the article to learn more about the advantages and disadvantages of each.

Alex DiCarlo
  • 4,851
  • 18
  • 34
  • As a side note, entire university courses are devoted to learning just the *introductory* topics and basics related to the questions you just asked, so don't expect to learn it overnight. (Although if you do, more power to you!) – Alex DiCarlo Jan 13 '13 at 06:06
  • thanks a lot dicarlo2 for your help I will appreciate if you can give me pointers to some tutorial or books for the university courses which you mentioned – Registered User Jan 13 '13 at 06:21
  • @RegisteredUser Sure, at UIUC these topics are briefly mentioned in the latter half of an intro computer architecture course and about half of a [systems programming](http://courses.engr.illinois.edu/cs241/fa2012/) course. The latter is probably the most relevant to the questions you asked, see the notes on memory in the link I provided. – Alex DiCarlo Jan 13 '13 at 06:26
  • I have heard of an exercise at UIUC which says to program a page table walk have you ever heard of it or done it if yes can you give me any link at UIUC site which is for the same – Registered User Jan 13 '13 at 09:05
  • @RegisteredUser Typically translating a virtual address to an entry in a multi-level page table is an exam question, and unfortunately I do not have a link handy for a past exam with one on it. – Alex DiCarlo Jan 13 '13 at 09:08
  • 1
    I should add that most apps have more than one stack while running, but there must be at least one - the one belonging to the thread created by the loader to run the code at the app execution entry point. That stack is, presumably, the one referred to in the diagram. – Martin James Jan 14 '13 at 13:23
  • @MartinJames Good addition, I'll probably omit editing my above answer in favor of upvoting your comment, increasing its visibility, as there are hundreds of things that could be added to the above answer and its fairly long already. – Alex DiCarlo Jan 14 '13 at 16:18
1

Part 1. The Stack ...

A function can call a function, which might call another function. Any variables allocated end up on the stack through each iteration. And de-allocated as each function exits, hence "stack". You might consider Wikipedia for this stuff ... http://en.wikipedia.org/wiki/Stack_%28abstract_data_type%29

B. Nadolson
  • 2,988
  • 2
  • 20
  • 27
1

Linux randomizes the stack, memory mapping segment, and heap by adding offsets to their starting addresses. Unfortunately the 32-bit address space is pretty tight, leaving little room for randomization and hampering its effectiveness.

I believe this is more of a generalization being made in the article when comparing the ability to randomize in 32 vs. 64-bits. 3GB of addressable memory in 32-bits is still quite a bit of space to "move around" ... it's just not as much room as can be afforded in a 64-bit OS, and there are certain applications, such as image-editors, etc. that are very memory intensive, and can easily use up the entire 3GB of addressable memory available to them. Keep in mind I'm saying "addressable" memory ... this is dependent on the platform and not the amount of physical memory available in the system.

Jason
  • 31,834
  • 7
  • 59
  • 78
  • I'm not even sure what randomizing the start of the stack, memory mapped segment, and heap segment would do, considering everything the process sees is a virtual address. – Alex DiCarlo Jan 13 '13 at 06:12
  • 1
    It's to prevent predictable security exploits, or at least make them a lot harder than if every process the OS managed had each portion of the executable in the exact same virtual memory location. – Jason Jan 13 '13 at 06:52
  • Ah, that statement definitely jars my memory, now I remember. It's possible the context of that quote mentions the security issues, and has nothing to do with the performance, as I had assumed it was referring to when it stated "effectiveness." – Alex DiCarlo Jan 13 '13 at 06:54