RFR: 8312132: Add tracking of multiple address spaces in NMT [v105]

[Thomas Stuefe]

On Mon, 27 May 2024 10:09:38 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Hm. We use ssize_t in many places for working with memory deltas, It works on all our platforms. And I don't see a good alternative here. int64 is not a replacement. To me, int64 feels like using void* for pointers, obfuscating intent. Its a memory size, I'd like therefore to see that in code. Apart from the obvious 64/32 bit problem.
>> 
>> One could probably use ptrdiff_t, but no pointers are involved, it seems awkward. 
>> 
>> One could use size_t+boolean tupels, and that may be the hypercorrect way. It would solve the problem of not being 
>> 
>>> Btw: Yes, I know, we can underflow or overflow the diff, but in practice no one will allocate 2**64 bytes, I am willing to take that risk.
>> 
>> An overflow would occur at 2**63. On 32-bit, on 2**31. So, on 32-bit you cannot express data sizes >= 2GB correctly. Which seems to me like a real limit. 
>> 
>> Maybe a size_t+boolean tupel is the right way to go.
>
> You can express large ranges with `int64_t`. There's no problem on 32-bit systems, just a bit of extra instructions emitted and some stack spillage. Also gah, I was sure that I wrote 63 and not 64 :-). Why not just typedef the `int64_t` as `delta` and call it a day?
> 
>>An overflow would occur at 263. On 32-bit, on 231. So, on 32-bit you cannot express data sizes >= 2GB correctly. Which seems to me like a real limit.
> 
> If anything, we should switch the `position` from `size_t` to `uint64_t` in `VMATree`.

int64_t as delta_t would be a pragmatic compromise. On 32-bit, it allows to represent the full +-4gb. On 64-bit, nobody cares for deltas > 2^63.

On 32-bit, the only annoying part then is casting to/from size_t.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18289#discussion_r1615923878