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

[Afshin Zafari]

On Thu, 20 Nov 2025 06:16:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

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

`const uintptr_t` is used.

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

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