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