RFR: 8334489: Add function os::used_memory [v2]

[Erik Österlund]

On Wed, 19 Jun 2024 16:44:01 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> I think in this case I'd prefer to have an ifdef LINUX in a single shared version in os.cpp rather than duplicating the function this way.
>
> @dholmes-ora 
> 
>> I think in this case I'd prefer to have an ifdef LINUX in a single shared version in os.cpp rather than duplicating the function this way.
> 
> That's nice, let's do that.
> 
> @tstuefe 
> 
>> You subtract available from physical. Why not free from physical?
> 
> `os::free_memory()` is just `available_memory()` on all of our platforms. I thought it was weird that we have two of them which are identical, so I just picked the one that is defined.
> 
>>What is your definition of used? Used, as in "used by user processes", or used as in "used by anything on the machine, including kernel-side caches"?
> 
> The latter, but machine can be replaced by "the container". To quote:
> 
>>[memory.current] Shows the total amount of memory currently being used by the cgroup and its descendants. It includes page cache, in-kernel data structures such as inodes, and network buffers.
> 
> That should be a viable explanation for the non-container case also.

> @jdksjolen You subtract available from physical. Why not free from physical? What is your definition of used? Used, as in "used by user processes", or used as in "used by anything on the machine, including kernel-side caches"?
> 
> 
> 
> I'd like to have good comments for the growing number of memory query APIs at some point. Maybe it would also be good to have a single compound API, platform-independent, akin to os::Linux::query_process_memory_info().

Just for some context... I'm working on automatic heap sizing for ZGC. Part of the heuristics want to reason about some sort of "memory pressure" on the machine, which is vaguely related to what portion of the machine or container memory is used vs not used. 

It struck me that with the existing APIs, I can't calculate what fraction of memory is neither used, free nor available. Because we only expose free and available which depend on the container size. And to calculate the fraction I would have to ask for the container size again. If the two reported sizes are inconsistent, you are bound to get nonsense values.

The used memory, i.e. memory that is not available, is the only number among these that stays invariant of the container size. And it's unfortunately the number we hide in the implementation of the others making it awkwardly not possible to get consistent fractions.

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

PR Comment: https://git.openjdk.org/jdk/pull/19772#issuecomment-2179315546