Some facts about "Segmented Paging"

1) Each process has one segment table.
2) There is one-page table per segment.

Fact about "Paged segmentation"

3) Contains page table of segment table.

Now consider following problem

In a paged segmented scheme of memory management, the segment table itself must have a page table because. (A) The segment table is often too large to fit in one page.
(B) Each segment is spread over a number of pages.
(C) Segment tables point to page tables and not to the physical locations of the segment.
(D) The processor’s description base register points to a page table

Given solution is:

Here option (A) is true , as segment table are sometimes too large to keep in one pages. So, segment table divided into pages. Thus page table for each Segment Table pages are created.

My Doubt

I believe a page can contain several hundreds of segment table entries of form

  <segment base, limit>

I only came across code, data, stack and heap segments. I believe a process can have only these "four" segments. And also, we know each process has a segment table (Fact 1). Then how a segment table can grow so large that it cannot be fitted in a single page?


2 Answers 2


A process can only access 6 segments simultaneously through CS, SS, DS, ES, FS, and GS registers on an x86 and x86-64 machines.

These registers point to an entry in the segment descriptor table that the operating system manages. If OS uses a multi-segment memory model then that table can have an arbitrary size thus allowing a process to access a theoretically unlimited number of segments. (Intel 64 and IA-32 Architectures Software Developer’s Manual 3-6 Vol.3)


I referenced Galvin and found this:

Normally, when a program is compiled, the compiler automatically constructs segments reflecting the input program.
A C compiler might create separate segments for the following:

  1. The code
  2. Global variables
  3. The heap, from which memory is allocated
  4. The stacks used by each thread
  5. The standard C library

Libraries that are linked in during compile time might be assigned separate segments. The loader would take all these segments and assign them segment numbers.

This explains how there can be multiple segments per process enough to grow the segment table so large that it cannot be fitted in a single page.

Further doubt:

From this, I can understand there can be multiple code segments each one for each referenced library. I was guessing if there can be multiple stack, heap and data segments. If yes, when?

  • $\begingroup$ If you have several threads, each one has it's own stack, at least. They might share heap, or have their own. $\endgroup$
    – vonbrand
    Commented Aug 16, 2019 at 13:13
  • 1
    $\begingroup$ If you have a further question, please ask it separately. You can certainly reference the original question that prompted yours. $\endgroup$
    – vonbrand
    Commented Aug 16, 2019 at 13:14
  • $\begingroup$ so its fixed, right? : one thread can have at max one stack? Yes I can understand that heap usually stores global variables, so its shared among various threads. But still I am guessing can there be any odd situation where a process can have multiple heap segments? $\endgroup$
    – RajS
    Commented Aug 16, 2019 at 13:31
  • $\begingroup$ As far as I can see (check your friendly assembler/linker manual for details), there is no (or only a ridiculously high) limit to the number of segments in a process. Which makes sense if you want to have shared libraries: each library is loaded separately into memory (thus sharable), and your program can certainly use a large set of disparate libraries (for C++, base C, the Boost libraries, handle a GUI, and furthermore handle e.g. a set of different formats of video/images, each with it's own library). $\endgroup$
    – vonbrand
    Commented Aug 16, 2019 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.