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

[Thomas Stuefe]

On Fri, 24 May 2024 08:57:38 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/nmt/vmatree.hpp line 146:
>> 
>>> 144:   struct SingleDiff {
>>> 145:     int64_t reserve;
>>> 146:     int64_t commit;
>> 
>> The typical type would be `ssize_t`, not int64. 
>> 
>> Apart from clarity, I am not sure how int64 would work on 32-bit.
>
> That doesn't seem right to me. `ssize_t` has a guaranteed range of `[-1, INT_MAX)`, the -1 being there for errors. We need as full of a range of negative numbers as possible.
> 
> Good question regarding 32-bit, will have to think about that one.
> 
> 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.

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.

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

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