RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11]

[Axel Boldt-Christmas]

On Thu, 20 Nov 2025 05:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> According to reviewers' suggestions, the pointers used in arithmeitc are typed as numeric like `size_t` or `uintptr_t`. And only when they are going to be passed as pointers to other functions, they will be cast to the desired pointers.
>
> Okay but why `size_t` in places and `uintptr_t` in others? In this case `zerobased_max` seems an address not a size - similar to `highest_start` and `lowest_start` in the other part of the change. But then `OopEncodingHeapMax` is `uint64_t` so why not use that?
> 
> I'm just not seeing the rules that are being applied here.

Not using `uint64_t` I think was to be pragmatic because it is a different type than `uintptr_t` (on MacOS iirc). One is `unsigned long long` and the other is `unsigned long`. Causes issues with overload resolution for templated functions. (Maybe that was just the issue with the similarly typed `UnscaledOopHeapMax`)

I think `OopEncodingHeapMax` is unfortunately typed. It might be intentional. Because we use it in two ways.
Either as the `Maximal size of heap`, or as the `zero based address: 0 + OopEncodingHeapMax` (the max end address of the `Maximal size of heap` Heap). In one case the type is more natural to be `size_t` and in the other it is `uintptr_t`. 

Right here though I agree type should be `uintptr_t`. We are using it as the max address our heap can end in.

I would much rather we had 
```c++
  const uintptr_t zerobased_max = OopEncodingHeapMax;


In my opinion `UnscaledOopHeapMax` `OopEncodingHeapMax` should be typed as size_t, better named (to reflect their compressed oop nature and that they relate to the `Maximal size of heap`) and only be available in 64-bit VM (as using these in a 32-bit VM smells buggy).
And when we want to use it as the max end address we put it in a `uintptr_t` typed variable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2544488536