RFR: 8357086: os::xxx functions returning memory size should return size_t [v7]

Kim Barrett kbarrett at openjdk.org
Thu Jun 12 10:30:30 UTC 2025


On Thu, 12 Jun 2025 08:43:47 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value type for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static size_t available_memory();
>> static julong used_memory(); --> static size_t used_memory();
>> static julong free_memory(); --> static size_t free_memory(); 
>> static jlong total_swap_space(); --> static ssize_t total_swap_space();
>> static jlong free_swap_space(); --> static ssize_t free_swap_space(); 
>> static julong physical_memory(); --> static size_t physical_memory(); 
>> 
>> 
>> The changes are done so that the other parts of the code have minimal impact. 
>> Tested in GHA and Tiers 1-4.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357086: Added missed casts.

> > D) a separate error reporting variable. It feels a bit overengineered, though.
> 
> I think I disagree with this. The status quo makes it all too easy to miss that you need to check the return value for an error. IMHO, this is a growing ground for bugs when someone starts to use any of these APIs with realizing that we're mixing two values (and two types) into one return value. Just 2c, to reiterate that _I_ wouldn't mind a solution like this.

I agree with @stefank here.  Also, these are not functions that would be helped by C++17 `[[nodiscard]]`.

Note that we already have a mechanism for propagating errors in HotSpot, via CHECK/TRAPS. Not beautiful but it
exists. This discussion makes me kind of wish we had something like [Boost.LEAF](https://boostorg.github.io/leaf/).
(Though probably trimmed down a bit, since there are features we don't need. And having anything like that likely
needed a more modern C++ than we had until relatively recently.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-2966060885


More information about the hotspot-dev mailing list