RFR: 8318127: align_up has potential overflow

[Andrew Haley]

On Sat, 21 Sep 2024 06:26:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/align.hpp line 76:
>> 
>>> 74: constexpr T align_up(T size, A alignment) {
>>> 75:   T mask = checked_cast<T>(alignment_mask(alignment));
>>> 76:   assert(size <= std::numeric_limits<T>::max() - mask, "overflow");
>> 
>> I don't really understand this assertion. `align_up((uint32_t)0fffff_ffff, 16) == 0`, because `uint32_t` is an unsigned type:
>> 
>> _An unsigned integer type has the same width N as the corresponding signed integer type. The range of representable values for the unsigned type is 0 to 2 N − 1 (inclusive); arithmeticfor the unsigned type is performed modulo 2**N_.
>> [Note 2 : Unsigned arithmetic does not overflow. Overflow for signed arithmetic yields undefined behavior ]
>
> The JBS issue is using "overflow" in the sense of "high bits of the mathematical result are discarded".
> Fixed-width unsigned arithmetic can certainly overflow in that sense.

Perhaps, although "overflow" has a precise definition in C++, but I would be extremely surprised if I were looking for the address of the end of the page at 0fffff_ffff and was informed of an overflow. IMO, _there is no overflow_ in that case, and the correct answer must be 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1770223524