RFR: 8281213: Unsafe uses of long and size_t in MemReporterBase::diff_in_current_scale [v3]
Afshin Zafari
duke at openjdk.org
Mon Dec 19 18:40:51 UTC 2022
On Mon, 19 Dec 2022 14:01:34 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:
>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>>
>> 8281213: Unsafe uses of long and size_t in MemReporterBase::diff_in_current_scale
>
> src/hotspot/share/services/memReporter.hpp line 82:
>
>> 80: assert(amount <= SIZE_MAX - _scale / 2, "size_t overflow");
>> 81: amount = (amount + _scale / 2) / _scale;
>> 82: // We assume the valid range for deltas [INT64_MIN, INT64_MAX] to simplify the code.
>
> In the assert the comment should be:
>
> We assume the valid range for deltas [-INT64_MAX, INT64_MAX] to simplify the code.
>
>
> I excluded the `INT64_MIN` case to simplify the code.
> The `INT64_MIN` case is when `sizeof(size_t) == sizeof(int64_t) && amount == INT64_MAX + 1 && is_negative == true`.
> For this case `-(int64_t)amount` is UB which needs proper handling.
> The code instead of
>
> return (is_negative) ? -(int64_t)amount : (int64_t)amount;
>
> would be more complex:
>
> if (!is_negative) {
> return (int64_t)amount;
> } else {
> return (amount != INT64_MAX+1) ? -(int64_t)amount : INT64_MIN;
> }
>
>
> This is why the assert part is `sizeof(size_t) == sizeof(int64_t) && amount <= INT64_MAX)`
>
> Maybe the better comment is
>
> // We assume the valid range for deltas [-INT64_MAX, INT64_MAX].
> // We excluded the `INT64_MIN` case to simplify the code.
I couldn't follow your idea.
The `INT64_MAX + 1` results in compiler overflow error. Isn't it equal to `INT64_MIN`?
-------------
PR: https://git.openjdk.org/jdk/pull/11514
More information about the hotspot-runtime-dev
mailing list