RFR: 8334489: Add function os::used_memory

Thomas Stuefe stuefe at openjdk.org
Wed Jun 19 13:29:09 UTC 2024


On Tue, 18 Jun 2024 15:53:17 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> A function os::used_memory is needed for GC ergonomics.
>> 
>> A naïve implementation is:
>> 
>> ```c++
>> julong os::used_memory() {
>>   return os::physical_memory() - os::available_memory();
>> }
>> 
>> 
>> This function does not work well in a containerized environment, as the amount of physical memory may change. To understand why, we must look under the hood.
>> 
>> ```c++
>> julong os::used_memory() {
>>   return os::physical_memory() - os::available_memory();
>> }
>> 
>> // can be expanded into
>> 
>> julong os::used_memory() {
>>   // The os::physical_memory() call
>>   julong mem_physical1 = OSContainer::memory_limit_in_bytes();
>>   // The os::available_memory() call
>>   julong mem_used = OSContainer::memory_usage_in_bytes();
>>   julong mem_physical2 = OSContainer::memory_limit_in_bytes();
>>   
>>   // Uh-oh: mem_physical1 may differ from mem_physical2 at this point
>>   // That means that this number is wrong
>>   return mem_physical1 - (mem_physical2 - mem_used);
>> }
>> 
>> 
>> The fix is to expose OSContainer::memory_usage_in_bytes if it's available, as this call does not depend on OSContainer::memory_limit_in_bytes. The default implementation will use the naïve implementation.
>
> @jerboaa , would you be so kind as to review this addition? This seems like something you'd know about.

@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().

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

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


More information about the hotspot-runtime-dev mailing list