5

The memory map of a process appears to be fragmented into segments (stack, heap, bss, data, and text),

  • I was wondering are these segments just an abstraction for the convenience of the process and the physical RAM is just a linear array of addresses or is the physical RAM also fragmented into these segments?
  • Also if the RAM is not fragmented and is just a linear array then how does the OS provide the process the abstraction of these segments?
  • Also how would programming change if the memory map to a process appeared as just a linear array and not divided into segments (with the MMU translating virtual addresses into physical ones)?
lychee
  • 1,771
  • 3
  • 21
  • 31
  • ad 3) from perspective of C(++) programmer memory **does** appear as a linear array managed by a memory manager so this part does not make sense to me. This whole question is very broad showing very little research effort. Examine similar Stack Overflow questions and then try to narrow this one. http://stackoverflow.com/search?q=%5Boperating-system%5D+paging+segmentation+answers%3A1.. – xmojmr Feb 02 '15 at 15:31
  • @xmojmr yes it does appear as a linear array, but it is divided into segments. – lychee Feb 02 '15 at 15:47
  • Why is question voted for closing? I don't think the subject is too broad. But definitely not a C question. I think you should remove that tag. – m0skit0 Feb 02 '15 at 15:49
  • yes, but in C(++) there's no language feature dealing directly with segments so programming is not affected. See [What is the advantage of using segment registers (today)?](http://stackoverflow.com/questions/26865242/what-is-the-advantage-of-using-segment-registers-today) and it's linked questions – xmojmr Feb 02 '15 at 15:50
  • @m0skit0 I added C because I'm asking from a C programmer perspective – lychee Feb 02 '15 at 16:08
  • As already stated out twice, from a C programmer perspective your question makes no sense. It just like adding a tag for "male" because you're asking from a male perspective. – m0skit0 Feb 02 '15 at 16:09
  • It should be asked from an OS perspective. – Martin James Feb 03 '15 at 13:13

4 Answers4

6

In a modern OS supporting virtual memory, it is the address space of the process that is divided into these segments. And in general case that address space of the process is projected onto the physical RAM in a completely random fashion (with some fixed granularity, 4K typically). Address space pages located next to each other do not have to be projected into the neighboring physical pages of RAM. Physical pages of RAM do not have to maintain the same relative order as the process's address space pages. This all means that there is no such separation into segments in RAM and there can't possibly be.

In order to optimize memory access an OS might (and typically will) try to map sequential pages of the process address space to sequential pages in RAM, but that's just an optimization. In general case, the mapping is unpredictable. On top of that the RAM is shared by all processes in the system, with RAM pages belonging to different processes being arbitrarily interleaved in RAM, which eliminates any possibility of having such "segments" in RAM. There's no process-specific ordering or segmentation in RAM. RAM is just a cache for virtual memory mechanism.

Again, every process works with its own virtual address space. This is where these segments can exist. The process has no direct access to RAM. The process doesn't even need to know that RAM exists.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • Can you provide a reference to an evidence? – xmojmr Feb 02 '15 at 15:52
  • Evidence? What's that, a criminal investigation or something? :) – dtech Feb 02 '15 at 15:55
  • @xmojmr Evidence? You mean reference? – m0skit0 Feb 02 '15 at 15:57
  • @xmojmr: Anything that describes the very basics of virtual memory? Wikipedia even? – AnT stands with Russia Feb 02 '15 at 16:06
  • Have you tried looking up the Wikipedia entry for [virtual memory](http://en.wikipedia.org/wiki/Virtual_memory)? – David R Tribble Feb 02 '15 at 16:36
  • @m0skit0 I mean the answer contains a lot of claims that something is/is_not in the disputable "_believe me_" style. By evidence/reference I mean at best clickable hyperlinks leading to a trusted information source supporting those claims and even better pointers to a source code of some "modern OS" where the said behavior can be clearly seen. At least some _dictionary terms_ that the OP can lookup in a dictionary like http://wiki.osdev.org. I don't know what's the correct English term for _verifiable proof_ so I used _evidence_ – xmojmr Feb 02 '15 at 18:56
  • @xmojmr: The claims I made are very basic "kindergarten-level" description of how virtual memory operates and the role RAM plays in it. It is not a "believe me" kind of answer. It is an "everybody knows that..." kind of answer. – AnT stands with Russia Feb 02 '15 at 19:11
  • @AndreyT I'm not trying to say that your answer is not useful. I'm trying to say that you provide **0** links to some further reading of what "everybody knows". Can you add some? BTW: the things OP calls segments "_..bss, data, and text.._" are used by executable image loader to setup process's initial memory, e.g. `bss` means do nothing, just allocate bunch of zeros, `text` means allocate read-only shareable memory and modern 64-bit OS using `long mode` with flat memory layout don't utilize the hardware segment registers. That's the "_disputable_" part as what you describe is `paging` – xmojmr Feb 02 '15 at 19:25
  • Googling 'virtual memory management' gives: 'About 8,370,000 results'. Surely, one or two would be useful? – Martin James Feb 03 '15 at 13:42
  • @xmojmr: The question was actually about RAM. The answer is that the role RAM plays in virtual memory systems completely eliminates any possibility of any process-level organization like splitting it into "..bss, data, and text..". It just doesn't even remotely apply. There's no point of discussing it the particularities of "..bss, data, and text..". The OP needs to take a step (or two) back from "..bss, data, and text.." and figure out first what RAM is. Once they do, most such questions will immediately "answer themselves". – AnT stands with Russia Feb 03 '15 at 15:38
  • @MartinJames Googling 'marting james is wrong' gives: 'About 149,000,000 results'. Surely, one or two would explain why. Do you find it useful approach to mine and collect knowledge? EOM NNTR – xmojmr Feb 03 '15 at 19:09
2

These segments are largely a convenience for the program loader and operating system (though they also provide a basis for coarse-grained protection; execution permission can be limited to text and writes prohibited from rodata).1

The physical memory address space might be fragmented but not for the sake of such application segments. For example, in a NUMA system it might be convenient for hardware to use specific bits to indicate which node owns a given physical address.

For a system using address translation, the OS can somewhat arbitrarily place the segments in physical memory. (With segmented translation, external fragmentation can be a problem; a contiguous range of physical memory addresses may not be available, requiring expensive moving of memory segments. With paged translation, external fragmentation is not a possible. Segmented translation has the advantage of requiring less translation information: each segment requiring only a base and bound with other metadata whereas a memory section would typically have many more than two pages each of which has a base address and metadata.)

Without address translation, placement of segments would necessarily be less arbitrary. Fortunately, most programs do not care about the specific address where segments are placed. (Single address space OSes

(Note that it can be convenient for sharable sections to be in fixed locations. For code this can be used to avoid indirection through a global offset table without requiring binary rewriting in the program loader/dynamic linker. This can also reduce address translation overhead.)

Application-level programming is generally sufficiently abstracted from such segmentation that its existence is not noticeable. However, pure abstractions are naturally unfriendly to intense optimization for physical resource use, including execution time.

In addition, a programming system may choose to use a more complex placement of data (without the application programmer needing to know the implementation details). For example, use of coroutines may encourage using a cactus/spaghetti stack where contiguity is not expected. Similarly, a garbage collecting runtime might provide additional divisions of the address space, not only for nurseries but also for separating leaf objects, which have no references to collectable memory, from non-leaf objects (reducing the overhead of mark/sweep). It is also not especially unusual to provide two stack segments, one for data whose address is not taken (or at least is fixed in size) and one for other data.

1One traditional layout of these segments (with a downward growing stack) in a flat virtual address space for Unix-like OSes places text at the lowest address, rodata immediate above that, initialized data immediately above that, zero-initialized data (bss) immediately above that, heap growing upward from the top of bss, and stack growing downward from the top of the application's portion of the virtual address space.

Having heap and stack growing toward each other allows arbitrary growth of each (for a single thread using that address space!). This placement also allows a program loader to simply copy the program file into memory starting at the lowest address, groups memory by permission, and can sometimes allow a single global pointer to address all of the global/static data range (rodata, data, and bss).

2

The memory map to a process appears fragmented into segments (stack, heap, bss, data, and text)

That's the basic mapping used by Unix; other operating systems use different schemes. Generally, though, they split the process memory space into separate segments for executing code, stack, data, and heap data.

I was wondering are these segments are just abstraction for the processes for convience and the physical RAM is just a linear array of addresses or the physical RAM is also fragmented into these segments?

Depends. Yes, these segments are created and managed by the OS for the benefit of the process. But physical memory can be arranged as linear addresses, or banked segments, or non-contiguous blocks of RAM. It's up to the OS to manage the total system memory space so that each process can access its own portion of it.

Virtual memory adds yet another layer of abstraction, so that what looks like linear memory locations are in fact mapped to separate pages of RAM, which could be anywhere in the physical address space.

Also if the RAM is not fragmanted and is just a linear array then how the OS provides the process the abstraction of these segments?

The OS manages all of this by using virtual memory mapping hardware. Each process sees contiguous memory areas for its code, data, stack, and heap segments. But in reality, the OS maps the pages within each of these segments to physical pages of RAM. So two identical running processes will see the same virtual address space composed of contiguous memory segments, but the memory pages comprising these segments will be mapped to entirely different physical RAM pages.

But bear in mind that physical RAM may not actually be one contiguous block of memory, but may in fact be split across multiple non-adjacent blocks or memory banks. It is up to the OS to manage all of this in a way that is transparent to the processes.

Also how the programming would change if the memory map to a process would appear just as a linear array and not divided into segments?, and then the MMU would just translate these virtual addresses into physical ones.

The MMU always operates that way, translating virtual memory addresses into physical memory addresses. The OS sets up and manages the mapping of each page of each segment for each process. Each time the process exceeds its stack allocation, for example, the OS traps a segment fault and adds another page to the process's stack segment, mapping the virtual page to a physical page selected from available memory.

Virtual memory also allows the OS to swap out process pages temporarily to disk, so that the total amount of virtual memory occupied by all of the running processes can easily exceed the actual physical memory RAM space of a system. Only the currently active executing processes actually have access to real physical RAM pages.

David R Tribble
  • 11,918
  • 5
  • 42
  • 52
1

I was wondering are these segments are just abstraction for the processes for convience and the physical RAM is just a linear array of addresses or the physical RAM is also fragmented into these segments?

This in fact highly depends on architecture. Some will have hardware tools (e.g. descriptor registers for x86) to split the RAM into segments. Others just keep this information in software (OS kernel information for this process). Also some segments information are totally irrelevant on execution, they're used merely for code/data loading (e.g. relocation segments).

Also if the RAM is not fragmanted and is just a linear array then how the OS provides the process the abstraction of these segments?

Process code never references to segments, he only knows about addresses, so the OS has nothing to abstract.

Also how the programming would change if the memory map to a process would appear just as a linear array and not divided into segments?, and then the MMU would just translate these virtual addresses into physical ones

Programming would not be affected. When you program in C you don't define any of these segments, and code also doesn't reference these segments. These segments are to keep an ordered layout, and don't even need to be the same across OS.

m0skit0
  • 25,268
  • 11
  • 79
  • 127