为什么进程的虚拟地址空间中有漏洞

Question

My textbook says that there are large holes in the virtual address space of a process that are not mapped to any meaningful data. But when we produce an execute object file, everything is determined such as .text, .data, shared objects etc, the only dynamic thing that might need to have gap is the stack.So where are other gaps from? why we don't compact everything just leave only a gap for the stack?

another question is, on the second picture, what's the difference between unallocated VM pages and unallocated pages?

Answer 1

In the first picture, there are three gaps in the virtual address space. The hole at 0 is there because it's useful; programming bugs often accidentally use a small integer as an address, so if the address is not mapped in the address space, the MMU hardware can detect it.

The hole at the end is because we haven't used all the address space!

The hole before the shared library may be there for several reasons. On many architectures, libraries have a 'preferred' address to be loaded at; putting them elsewhere requires relocation work, and probably some unshared pages. Locating them "arbitrarily" makes certain hacks somewhat harder than if all systems had library X at a predictable address. And lastly, you forgot about the heap - a region for dynamically-allocated memory, often placed after the data allocated by the object file.

In the second diagram, "unallocated VM pages" seems to mean space for which there is nothing in the page tables. "Unallocated pages" have entries in the page tables, so in some sense they are a little closer to existing. I'm not sure what point the author wants to make, though. It's not really important to the executing program itself.

As to why the address space is not compacted: it does not gain anything. The scarce resource is real memory, not (usually) compacted address space. It's a positive benefit to be able to deliberately have holes, so that data can expand if necessary.

Answer 2

Your diagram is a gross oversimplification. This is not correct:

But when we produce an execute object file, everything is determined such as .text, .data, shared objects etc,

Things like text and data are collections in the executable file. The do not exist in memory.

In 64-bit system, you have over a billion gigabytes of addressable space. No application in existence comes close to using that much memory so there will be holes in the address space.

Holes are used for protection. Most systems leave the lowest page unmapped to create a trap for null pointers. Some systems put gaps around the stacks to trap overflows and underflows.

There is a range of system addresses. Those are generally reserved but there is much unused space. That creates holes.

If you tried to keep a contiguous usable address range, you create the problem of having to keep memory contiguous. That creates all kinds of allocation problems.

another question is, on the second picture, what's the difference between unallocated VM pages and unallocated pages?

I suspect that they are trying to illustrate the difference between pages that are not mapped to the address space (ie, those that are completely invalid) and pages that are paged out to secondary storage (ie, those that will trigger a page fault if accessed).