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

[Thomas Stuefe]

On Fri, 13 Jun 2025 07:33:56 GMT, Anton Artemov <duke at openjdk.org> wrote:

> > FWIW, I think that the `ssize_t` was a good first step and the `MemRes` was an experiment that would be interesting to see if how that panned out, but I didn't expect to see it in this PR. It tried to convey that in an earlier comment. I'm leaving it up to the other involved reviewers to decide if we should go with the MemRes change in this PR.
> 
> I understand that. Keeping `ssize_t` would not introduce consistency in the codebase, as on Windows `ssize_t` is `int64_t`, which is a signed type and, as pointed out by @tstuefe, it eats half of the possible range. I am not sure about other platforms, but I suspect that would not be the case there. Therefore I decided to rely on the known things such as `size_t `. But then, if we want to report more than one kind of error, it makes sense to keep the error code separately.

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 end the JVM and return false to the caller, all he then needs to decide is if the missing value is important to him. Printing functions would not care beyond writing "no data" or some such. Java heap initialization may want to terminate the JVM early if we cannot e.g. determine the physical_memory() size.

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

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