RFR: 8354803: ALL_64_BITS is the same across platforms [v2]

[Stefan Karlsson]

On Wed, 23 Apr 2025 11:02:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   handle windows too
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 165:
> 
>> 163: 
>> 164: // for timer info max values which include all bits
>> 165: #define ALL_64_BITS CONST64(0xFFFFFFFFFFFFFFFF)
> 
> I was thinking perhaps
> 
> const jlong ALL_64_BITS ...
> 
> ?

I was going to write something about that this could risk promoting even more usages of jlong, which would be unfortunate because I think that many of us are of the opinion that we should try to confine these j* types from a large portion of the JVM. So, I would have hoped for name that would show that the type was jlong and thereby deterring people from using it freely. Maybe `all_bits_jlong` to match `min_jlong` and `max_jlong`.

And then I remembered that all this is big mess.
* You can't even compile `CONST64(0xFFFFFFFFFFFFFFFF)` with -Wconversion on mac because you get:

src/hotspot/share/utilities/globalDefinitions.hpp:299:27: error: implicit conversion changes signedness: 'unsigned long long' to 'const jlong' (aka 'const long') [-Werror,-Wsign-conversion]
const jlong ALL_64_BITS = CONST64(0xFFFFFFFFFFFFFFFF);
            ~~~~~~~~~~~   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
``` 

* CONST64's usage of LL doesn't match the definition of jlong which is `long` and not `long long`.

I think all these concerns can be fixed by doing:

const jlong all_bits_jlong = ~jlong(0);


?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24715#discussion_r2055947313