Get available memory stats OSX

I know we could do RTFM here, but but what are the functions (REAL/Xojo or MBS or Declares) where I can get the 4 memory listings that are in the Activity Monitor in OSX?


I did do some looking and is getrusage() part of this whole equation?

[code] dim theDarwin as DarwinVMStatisticsMBS = GetDarwinVMStatisticsMBS
if theDarwin = nil then Return
dim theTaskInfo as new DarwinTaskInfoMBS
if theTaskInfo = nil then Return
dim thePageSize as Double = theDarwin.Pagesize // make a double to avoid integer overflow problems

LogItem "Total physical Memory: " + FormatMemory(SystemInformationMBS.PhysicalRAM)
LogItem "Physical Memory used by app: " + FormatMemory(theTaskInfo.ResidentSize)
LogItem "Free physical Memory: " + FormatMemory(thePageSize * theDarwin.FreePages)
LogItem "Total virtual Memory: " + FormatMemory(thePageSize * theDarwin.InactivePages + thePageSize * theDarwin.ActivePages + thePageSize * theDarwin.FreePages + thePageSize * theDarwin.WiredPages)
LogItem "Virtual Memory used by app: " + FormatMemory(theTaskInfo.VirtualSize)
LogItem "Free virtual Memory: " + FormatMemory(thePageSize * theDarwin.FreePages)[/code]

where FormatMemory is:

Private Function FormatMemory(d as double) As string

Return Format(d/1024,"-0")+" KB" // if you see a minus, we have an integer problem End Function

assuming of course that you purchased MBS

He did :slight_smile:
Thanks Beatrix for answering.

You could also run a Shell with “vmstat” as command.

Thanks Eli and Beatrix; Beatrix, I’ll use this. I have a memory leak in my C++ dylib I’m trying to track, I like going to REAL/Xojo to use certain functions and this seems easier.

I’ve always found it strange that even given 32Gb of memory, it’s easy to “run out” with plenty of RAM to spare. Memory allocation in OS’s certainly isn’t perfect, though I’m sure it’s great for most uses.

In a 32bit system, you may have 32GB or more installed but an app will only able to use a 4GB chunk of it max.

vm_stat in my OSX (10.10)

or use top

top -l 1 | head -n 10 | grep PhysMem | sed ‘s/, / /g’

Thanks, I think though the client is running 10.9 or 10.10 so it’s 64-bit only. But are you speaking of the REAL/Xojo app? I am. Then it’s running 32-bit which means it only accesses 4GB. Right?

So given that, whats a proper way to interpret the Activity Monitor settings? Just subtract 28GB from the Free totals?

You’re really more interested in the stats for a specific PROCESS not machine wide

So given that sort of changes my question; Norman, how would you monitor this sort of thing? (Basically at a certain point time after processing many files a memory allocation new() in my C++ dylib fails. I now this isn’t a Xojo-specific quesiton but it is the Xojo app running this dylib and I can use Xojo or Xojo-accessible functions to get this info.

Xojo doesn’t monitor your dylib and its memory usage - I’m not sure it even can
I could very well be wrong on that though

top can monitor your app rather than every process if you invoke it with top -pid and the process id of your running app

you can get the pid usually using the pid command - I think that will work in a shell
or you could declare into the std c library as there is a call there to get the current process pid

or you could use the same top command shown but combine a grep for the specific process name

but you DO want to monitor the PROCESS not the MACHINE since a 32 bit process (a Xojo app) IS limited to 4Gb total

the LEAKS command might be of use tracking this down

Thanks - but isn’t a dylib called by Xojo within it’s process space so it for all intents and purposes part of the app?

Process space yes
But if the dylib isn’t a plugin things like runtime object count etc are’t part of that
A malloc in a dylib isn’t something the runtime can track - its outside the scope of what the runtime knows about

OK, I understand your context now. I’ll try “top” - gosh I remembering using that in Linux for server process activity.

Maybe Apple’s instruments can help you find the bug too. Of course they do not integrate with the Xojo debugger but finding the API method name that caused a leak is often valuable help.

And a late reply on:

Activity monitor gives you the memory usage of each running process, so no need to subtract anything as long as you’re running a 32bit app. The limit on such is indeed 4GB of application RAM.