how XCode to calculate Memory

#include <os/proc.h> in the bridging header works on a test app I built.

In my project there is a lot of metal code. There is already a Bridging Header to facilitate that. (It defines a lot of C structures. Not my area of the code) When I add #include <os/proc.h> to that header the build fails withe error:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.2.sdk/usr/include/sys/cdefs.h:825:2: Unsupported architecture

in cdefs.h

#if   !defined(__sys_cdefs_arch_unknown__) && defined(__arm__)
#elif !defined(__sys_cdefs_arch_unknown__) && defined(__arm64__)
#else
#error Unsupported architecture
#endif

There are at least six os/proc.h files on my Mac picking one at random I see:

 * If you need more information than just the available memory, you can use task_info().
 * The information returned is equivalent to the task_vm_info.limit_bytes_remaining
 * field. task_info() is a more expensive call, and will return information such
 * as your phys_footprint, which is used to calculate the return of this function.

This seems to mean that I could substitute the code you supplied above which does some magic and returns task_vm_info_data_t.limit_bytes_remaining? You recommend against this but the value returned in a simple test is the same.

Oh, I hadn’t noticed that the docs for os_proc_available_memory explicitly state that it’s equivalent to limit_bytes_remaining. Given that, it’s reasonable for you to use the latter.

Having said that, Mach APIs are notoriously hard to use correctly, and os_proc_available_memory is specifically documented as being more efficient, so I’d still lean towards using it.

When I add #include <os/proc.h> to that header the build fails withe error

Hmmm, C include file problems. Fun times!

There are many build settings that affect how Clang searches for include files, so it’s hard to pinpoint exactly what’s causing this. I usually attack this using the Product > Perform Action > Preprocess command. That’s not available for Swift (no preprocessor, yay!) but you can do the following:

1. Add a new dummy .c file to your project.

2. Edit it to #include your bridging header.

3. Choose Product > Perform Action > Preprocess.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Many thanks for the #include <os/proc.h> workaround and information about os_proc_available_memory(). I'm running into the same issue where it won't compile without that extra line in the bridging header, though it compiles fine for me once I add that extra include.

I've also submitted a Feedback with FB10994534.

Thanks!

Quinn, you mention the following...

Cool. Using these APIs in internal tools like this is perfectly OK. I get worried when folks try to use them in their shipping app.

Is there any recommended API in which one could use for a shipping their application to obtain this information? This would be for a device monitoring application. I am asking as this post is 4 years old and well, Apple likes to add fresh technologies once a year!

Is there any recommended API in which one could use for a shipping their application to obtain this information? This would be for a device monitoring application.

Please start a new thread for this. There are a couple of reasons that makes sense:

• Your goal is different from the original poster, who was building a test tool to deploy internally.

• DevForums’s ability to deal with long threads is… well… let’s just say… less than ideal.

Feel free to link back here if you want to reference something specific.

Also, in your new post, please let us know:

• What platform you’re targeting?

• What you mean specifically by “this information”?

Oh, and use the Kernel tag so that I see it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Your goal is different from the original poster, who was building a test tool to deploy internally.

Yes, and no.

Awareness of available resources is very important to maintain for serious computing that stretches the capabilities of the underlying hardware.

This I am doing. We cannot do everything we want because the hardware of the iPad is not infinitely capable (have to wait for M3 for infinity mode, I guess)

We can do less than what the iPad is capable of because we cannot approach the limits, we have to keep well clear of them in case we hit them.

I come from a much more pure Unix programming environment where this sort of thing is easy. It is terribly difficult in iOS.

I am very interested in knowing how much memory the next allocation is going to use (sizeof(..)), and how much memory is left (not really a fixed target, and impossible to really know but most platforms have a way to estimate: get_avphys_pages (3) or GlobalMemoryStatusEx.

This bit me when loading and processing images on an iPad. Not a core activity, but it mattered. It turned out not to be limitations of the iPad that caused the problem, but some other (non apple) system. So I dropped it.

But this sort of thing comes at you, as an applications programmer, out of the blue.

It would be very helpful if Apple would address this directly, rather than the oblique fashion that you do.

It is not needed often, but when it is needed it is a life saver and makes for much better user experience in the end.