Sorry that I brought virtual memory into the discussion. What I meant was
the same thing that in some cases the virtual memory usage is more than
physical memory usage, but in some cases physical memory usages can rise
even if the virtual memory usage falls. Like I know that virtual is always
higher than physical. My point was that lowering physical memory usage is a
complex topics and generally programmers want to give control to do
implementation, since they have a whole infrusture and we don't.

On Fri, 17 Apr 2026, 9:40 pm Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> 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.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>