Date: Fri, 17 Apr 2026 09:39:59 -0700
On Friday, 17 April 2026 06:59:09 Pacific Daylight Time Muneem via Std-
Proposals wrote:
> Again, the user generally cant fully optimize for space because
> modern operating systems are more complicated in that they have paging
> facilities that can lead to higher PHYSICAL memory usage even if the
> virtual memory usage is low, basically, the implementation knows how to
> avoid this, but as a programmer you dont.
Quick correction: it's the other way around.
Aside from bookkeeping overhead (such as the page tables), for every physical
page you *need*, there's a virtual page assigned to you, so your virtual
memory footprint is almost always larger than the physical memory footprint.
You're far more likely to have lower physical memory requirements than
virtual, for mostly two reasons: shared memory (all of the *code* pages you're
using are sharable) and unused virtual space, including guard pages.
In the past this may have been the other way around. The technique was called
"overlay" usually applied to swap not RAM, but I haven't seen it since my DOS
days. Back then, it was common for large applications to make explicit system
calls to EMM386 to page high memory in and out of your addressable space. In
even older systems too - for example, I think the Apollo Guidance Computer had
more memory than it could address, so there was a system register the software
could modify to toggle which physical bank of memory a portion of the
addressable space was referring to.
But this hasn't been true since we got to protected mode and 32-bit
applications, because 4 GB of addressing space was plenty. We have not added
explicit paging to software to overcome the 4 GB limit; instead, software that
needs to be bigger has instead migrated to 64 bits. For OSes themselves, we
may have returned to this for a brief period with 32-bit x86 PAE support.
Strictly speaking, OSes could have used segmentation to have effective 45 bits
of virtual address space, but I don't think they were making use of that.
Proposals wrote:
> Again, the user generally cant fully optimize for space because
> modern operating systems are more complicated in that they have paging
> facilities that can lead to higher PHYSICAL memory usage even if the
> virtual memory usage is low, basically, the implementation knows how to
> avoid this, but as a programmer you dont.
Quick correction: it's the other way around.
Aside from bookkeeping overhead (such as the page tables), for every physical
page you *need*, there's a virtual page assigned to you, so your virtual
memory footprint is almost always larger than the physical memory footprint.
You're far more likely to have lower physical memory requirements than
virtual, for mostly two reasons: shared memory (all of the *code* pages you're
using are sharable) and unused virtual space, including guard pages.
In the past this may have been the other way around. The technique was called
"overlay" usually applied to swap not RAM, but I haven't seen it since my DOS
days. Back then, it was common for large applications to make explicit system
calls to EMM386 to page high memory in and out of your addressable space. In
even older systems too - for example, I think the Apollo Guidance Computer had
more memory than it could address, so there was a system register the software
could modify to toggle which physical bank of memory a portion of the
addressable space was referring to.
But this hasn't been true since we got to protected mode and 32-bit
applications, because 4 GB of addressing space was plenty. We have not added
explicit paging to software to overcome the 4 GB limit; instead, software that
needs to be bigger has instead migrated to 64 bits. For OSes themselves, we
may have returned to this for a brief period with 32-bit x86 PAE support.
Strictly speaking, OSes could have used segmentation to have effective 45 bits
of virtual address space, but I don't think they were making use of that.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-04-17 16:40:08