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

Johan Sjölen jsjolen at openjdk.org
Mon May 27 10:12:18 UTC 2024


On Sat, 25 May 2024 06:01:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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.

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`.

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

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


More information about the hotspot-dev mailing list