What about 64-bit systems, how would that address space look like?
Well the idea is exactly the same.
We have a per process address space, which is 8 TB,
which is a large, a very, very large amount of memory,
which we can't fill with today's applications,
starting from address 0 to address 7 and a lot of Fs here.
And then system space starts at address FFFF08,
then a bunch of 0s, and goes up to all Fs,
which is the highest 64-bit address possible,
and everything here is system space.
And there's various types of memory here including the
system working set and the kernel, the HAL,
the driver, the system cache, and some other stuff we haven't talked about yet,
but in general that's the same idea, all this memory looks like the same,
looks the same from whatever process context we're looking from,
and it's inaccessible from user mode as usual.
However, we can see here that the address space is not filled up completely.
In fact,
we can see there's 8 TB here and there's 8 TB starting from
this address where system space resides.
There is an unmapped region here, and that unmapped region,
which may look like some small amount of memory is actually about
a million times larger than everything else.
And that's because 64-bit addresses are gigantic,
I mean the other space is something we can't even imagine today,
or even in the foreseeable future,
and so most of it can't really be mapped at all.
So let's see what are these limitations, where do they come from?
So 64-bit addresses theoretically can get us to 2 to the 64th power,
that's 16 EB of memory.
Exabyte is something that you may not be familiar with
because it's relatively used pretty rarely,
and that's something that's here, let's see.
There's a kilo, there's a mega, there's a giga,
there's a tera, which we use sometimes, and then there's peta,
and finally there's exa.
That's a really large number.
So this address space is something we can't really comprehend,
so I don't see any 128-bit systems coming up to the floor anytime soon.
That's really something we can't use today, or or useless today by any system.
More than that, current CPU architectures,
that is by Intel and AMD,
don't support more than 48 bits of addressing because 64
bits is simply too much for today's system,
so it supports only 48 bits of addressing,
and that gives us something like 256 TB of memory that are
possible to be used with current processors,
and that's still a gigantic amount of memory.
However, Windows currently can't work with more than 16 TB of memory,
and that's because of some implementation details inside the kernel.
Specifically,
there is something known as a single list entry and there's an
instruction in the processor that do some things to that entry
in an atomic single instruction way,
and that must work with a 64-bit address in a certain way,
with a ceratin size, and that can't work with larger addresses than 16 TB.
So currently Windows implementation is limited to 16 TB of memory,
that's why we have the 8 TB for the user processes
and another 8 TB for the system.
We can imagine that in the future when that would be required or advisable,
we can lift that 16 TB of memory and increase that up to
256 TB by using a different instruction or using more than
one instruction and so on.
So currently we can use 8 TB for each process and 8 TB for a
system and still that's an enormous amount of memory that can't be
really filled today by any application,
we don't have that match of physical memory and we
don't have such large page files,
but theoretically that's something we can use and perhaps we'll need some time in the next decade or so.