使用Objective-C以编程方式释放系统内存 [英] Programmatically free up system memory using Objective-C

问题描述

所以，这就是我想要做的:

• 以purge命令的相同方式(尽管以编程方式)释放系统内存(非活动内存).

我已经在这里尝试了该代码(作者声称它可以工作)，但是它所做的只是使Mac OS X冻结:

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;
        }

    }
}

有什么想法吗?

解决方案

现实是代码没有执行-并将永远不会执行它所声称的功能.是垃圾.

它所要做的就是破坏系统的缓冲区缓存子系统，并有可能使计算机快速进入分页状态，从而导致看起来完全像是锁定的症状.尤其是在具有慢速硬盘驱动器(例如5400rpm笔记本电脑驱动器)的系统上.

至少，在具有相对少量RAM的系统上.在具有大量RAM且运行的应用程序负载相对较小的系统上，该程序将逐出2GB的缓冲区高速缓存，这会导致各种I/O操作的速度变慢，因为需要从磁盘中重新读取各种内容，而不是真正帮忙.

也不需要任何此类事情；如果应用程序需要内存，则系统将根据需要从缓冲区高速缓存中逐出页面和/或将内存页面调出到磁盘(在OS X上-在iOS上，没有能够大量写脏页面以保持响应能力的分页器).

调出purge将退出各种磁盘缓冲区高速缓存并在冷启动时模拟条件，但是-再次-这只会破坏系统的高速缓存机制，而实际上并未提高用户级应用程序的性能.如手册页所述，它对于在冷缓存状态下测试应用程序性能非常有用，但是即使purge不会驱逐所有可以驱逐的东西，这还是有点可疑的.不会干净地模拟寒冷状态.

就Steve Jessep的观点而言，在某些情况下，调用purge(或类似内容)可能会提高性能.在一般情况下，这通常-几乎是普遍的-会崩溃，因为用户进程A无法知道用户进程B，C，D，...，Z在附近或附近的任何时候可能会做什么遥远的未来.例子;可能只有清除RSS订阅源抓取器R删除了要解析和保留的MB MB的XML，立即使清除无效，才能清除这些东西.更糟糕的是，R的最后一次刷新可能仍在缓存中隐藏一些位，因此R的I/O刷新重磅使其变得既慢又昂贵(包括消耗电池寿命).

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?

解决方案

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

这篇关于使用Objective-C以编程方式释放系统内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！