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

[Afshin Zafari]

On Tue, 25 Nov 2025 10:14:39 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

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

For your suggested changes, I need them be more precise and explicit to be able to implement. TIA

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

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