Question

So, this is what I’m trying to do :

• Free up system memory (inactive memory), in the same fashion the purge command does, though programmatically.

I’ve tried the code here (which its author claims it works), but all it does is to cause Mac OS X to freeze :

void
free_up_memory()
{
    int c;
    char *p, *q;

    for(c = 0; c < 2048; c++)
    {
        if(!(p = malloc(1024 * 1024)))
        {

            return;
        }
        for(q = p; q < p + (1024 * 1024); q += 4096)
        {
            *q = 1;
        }

    }
}

Any ideas?

Answer 1

The reality is that code is not doing — and will never do — what it claims. It is garbage.

All it is going to do is undermine the system’s buffer caching subsystem and likely drive the machine into paging rapidly, causing symptoms that look entirely like a lockup. Especially on a system with a slow (5,400rpm laptop drive, for example) hard drive.

At least, on systems with relatively small amounts of RAM. On systems with larger amounts of RAM and relatively light load of apps running, that program is going to evict 2GB of buffer caches, causing various I/O operations to be slower as various things need to be re-read from disk, and not really help anything.

Nor should any such thing be necessary; if an app needs memory, the system will evict pages from the buffer caches and/or page out memory to disk as needed (on OS X — on iOS there is no pager capable of writing dirty pages largely to preserve responsiveness).

Calling out to purge will evict the various disk buffer caches and simulate conditions at a cold boot, but — again — that just undermines the system’s caching mechanisms without actually increasing performance for user level apps. As the man page documents, it can be quite useful for testing app performance in a cold cache state, but even that is a bit dubious in that purge won’t evict everything that can be evicted; won’t cleanly simulate a cold state.

To Steve Jessep’s quite valid point, there may be situations where a call to purge (or the like) might increase performance in that case. This typically — almost universally — falls apart in the general case in that there is no way for user process A to know what user processes B,C,D,….,Z might do at any point in the near or distant future. Example; A might go and purge stuff only to have RSS Feed Scraper R rip down a few MB of XML to be parsed and persisted, immediately invalidating the purge. Worse, R’s last refresh may have had bits still lurking in the cache such that R’s refresh pounds on I/O making it both slower and more costly (including costing battery life).