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

[Anton Artemov]

On Fri, 13 Jun 2025 10:14:22 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 MemRes available_memory();
>> static julong used_memory(); --> static MemRes used_memory();
>> static julong free_memory(); --> static MemRes free_memory(); 
>> static jlong total_swap_space(); --> static MemRes total_swap_space();
>> static jlong free_swap_space(); --> static MemRes free_swap_space(); 
>> static julong physical_memory(); --> static MemRes physical_memory(); 
>> 
>> 
>> `MemRes` is a struct containing a pair of values, `size_t value` to carry the return value, `int error` to carry the error if any. Currently, in case of error the latter is set to -1.
>> 
>> 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 default val to constructor of MemRes.

> What caller really needs multiple error codes? We want to know a memory size, and we may get it or not. If we don't get it, I don't think it matters why we don't get it. I don't see any different actions taken _by the caller of os::xxx()_ in reaction to what cog in the machine exactly failed. The end user needs a way to get detail information, but that can be done with UL logging down in the function itself. In addition, for very severe errors the function could end the JVM right away themselves, no need to even return to the caller. Example: if /proc is missing.

If we don't really need multiple error codes, then having a struct is redundant, as the the **only** error value can be encoded as something like `std::numeric_limits<size_t>::max`. I think it is safe to assume that this value will never be returned as a real memory size on any platform.

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

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