A few FFM questions
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Jul 12 11:48:18 UTC 2023
On 10/07/2023 16:02, Brian S O'Neill wrote:
> 1) The size limit of a memory segment is defined by a signed value,
> thus limiting the address space to be 63-bit. Is it likely that all
> 64-bit architectures today and in the future only use the lower half
> of the address range?
Did some more research on this, and found out that, in practice, this is
not an issue because:
1. existing platforms (x64 [1], ARM [2]) can only use 48/52 bits of
addressable space (although, Intel is in the process of updating this to
57 [3]).
2. bigger virtual addresses means bigger/deeper page translation tables
(again, see [3]), so the whole thing requires a lot of careful
consideration from HW vendors (e.g. it's not just matter of "adding more
bits")
3. OS typically come with their own set of policies which might restrict
address space even further. E.g. Windows uses 48 bits [4]. Also, it is
very common for OS to reserve negative addresses for Kernel space, and
leave positive addresses to user processes [5] (and also use some kind
of sign extension where all the unused bit, except the sign, are copied
from the most significant bit).
All this to say that creating a static segment which starts at 0 and
ends at Long.MAX_VALUE is likely a good enough approximation for the
entire user address space, given how many systems work in practice (and
will likely continue to do so for the foreseeable future).
[1] - https://cdrdv2.intel.com/v1/dl/getContent/671436
[2] -
https://developer.arm.com/documentation/101811/0103/Address-spaces/Size-of-virtual-addresses
[3] -
https://www.intel.com/content/www/us/en/content-details/671442/5-level-paging-and-5-level-ept-white-paper.html
[4] -
https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces
[5] - https://www.kernel.org/doc/html/v5.8/x86/x86_64/mm.html
More information about the panama-dev
mailing list