JDK-8357570 : [macOS] os::Bsd::available_memory() might return too low values
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 25
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • OS: os_x
  • CPU: generic
  • Submitted: 2025-05-22
  • Updated: 2025-05-23
Related Reports
Relates :  
Description
Currently   os::Bsd::available_memory()   returns on macOS 
vmstat.free_count * os::vm_page_size();

But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too  :
https://github.com/openjdk/jdk/pull/25384/files
// Available here means free. Note that this number is of no much use. As an estimate
// for future memory pressure it is far too conservative, since MacOS will use a lot of unused memory for caches, and return it willingly in case of needs.

See also the discussion here : https://github.com/giampaolo/psutil/issues/1277
At least (parts or all of) the other memory categories  inactive_count and maybe speculative_count  .

Looking at the HS API description 
https://github.com/openjdk/jdk/blob/428d33ef3ca0af34d8f164fe9d9b722e81e866a7/src/hotspot/share/runtime/os.hpp#L336
we want to have a  distinction between "available" memory and "free memory" so adding freeable categories might make sense .


There is a bit of additional information here https://developer.apple.com/forums/thread/118867
that confirms that free memory / free_count is only a fraction of what is available :  "Specifically, any report on the amount of free memory is unlikely to be useful."  .
Comments
[~mbaesken] No idea tbh. Whatever gets us the closest to how we understand "available memory". So, whatever matches Linux' description (see poc file system doc on Linux on /proc/meminfo)
22-05-2025

[~stuefe] what categories should we add on macOS ? Is free_count + inactive_count enough ? Unfortunately the manpage I found here is not very useful : https://developer.apple.com/documentation/kernel/vm_statistics64_data_t
22-05-2025