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

[Axel Boldt-Christmas]

On Wed, 27 Aug 2025 11:24:07 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

I agree with Johan that we cast this to a pointer to early. I much prefer `uintptr_t` rather than `char*` when doing byte sized pointer arithmetic on values which represent address which are not supposed to be dereferenced.

In this particular instance, in `HeapReserver::Instance::reserve_compressed_oops_heap` we might want to read `HeapBaseMinAddress` as:
```C++
 uintptr_t aligned_heap_base_min_address = align_up(MAX2(HeapBaseMinAddress, alignment), alignment);

Because `aligned_heap_base_min_address` is used later directly as an address. (We might instead want to propagate non pointer types further, but it will be a larger refactoring that is probably not suitable for this rfe).

Regardless I feel like we should not change the public "API" of HeapBaseMinAddress in a bug fix, I would rather we simply treat the value of HeapBaseMinAddress as a heap base minimum address and use it as a lower bound. No OS we run on (afaik) will let us reserve an address space where 0 can be dereferenced. 

I also wonder how we got here with `HeapBaseMinAddress == 0` as we set the value back to the default if it is lower when using compressed oops (in `Arguments::set_heap_size()`). And I think the default is 2G on all platforms.

_There seems to be a lot of pre-existing weirdness / corner cases in this code_

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

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3232561871