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

[Axel Boldt-Christmas]

On Tue, 16 Sep 2025 09:06:42 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uintptr_t -> uint64_t

What is the reasoning behind using `uint64_t` rather than `uintptr_t`?

I prefer the use of `uintptr_t` for values which describe addresses. While `uint64_t` will always have the same size as `uintptr_t` here (because this is 64-bit only coops code), it does not convey the same meaning to me. 

If anything the pre-existing type of `unscaled_end` may be wrong. Because end makes sound like an address in this context, but it is describing an offset. And is only used to check for an underflow before we may reinterpret it as an address (0 + offset).

That part I think would read much better by checking for the underflow first:
```C++
      uintptr_t lowest_start = aligned_heap_base_min_address;
      if (size <= UnscaledOopHeapMax) {
        lowest_start = MAX2<uintptr_t>(lowest_start, UnscaledOopHeapMax - size);
      }
      lowest_start = align_up(lowest_start, attach_point_alignment);


I think the use of `uint64_t` stems from the `UnscaledOopHeapMax` and `OopEncodingHeapMax` being typed as such. Unclear to me why they are not just `size_t`, as coops is a 64-bit VM feature.

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

PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3233193487