UNIX по сравнению с освобождением памяти Windows

Другие плакаты прокомментировали платформу определенный угол. Но так как Вы спрашиваете конкретно о malloc, позволяет, видят то, что говорит Стандарт C:

"Бесплатная функция заставляет пространство, на которое указывает ptr быть освобожденным, то есть, сделанным доступный для дальнейшего выделения".

Который кажется довольно ясным требованием, чтобы память не была возвращена к ОС. Вы иногда видите, что программы полагаются на это поведение:

int main(void)
{

    void *p = malloc(AS_MUCH_MEMORY_AS_I_WILL_EVER_NEED);

    if (p != 0)
    {
        free(p);
        /* malloc should always work for rest of program */
    }
}

Однако, когда этот вопрос подошел на comp.lang.c, некоторые плакаты указали на этот раздел:

"Функция malloc возвращает или нулевого указателя или указатель на выделенное место".

Это предполагает, что любой вызов к malloc может перестать работать. Кажется, что намерение Стандарта состоит в том, что память не возвращается к ОС, но вопрос не на 100% определен в глазах адвокатов языка.

Единственной операционной системой, где Вы не можете легко отдать выделенную память к системе, является OS X - заключающий использование памяти Firefox 3 в кавычки:

После обширного тестирования и подтверждения от сотрудников Apple мы поняли, что не было никакого пути к средству выделения для возвращения неиспользованных страниц памяти при сохранении диапазона адресов зарезервированным.. (Можно не отобразить их и повторно отобразить их, но это вызывает некоторые условия состязания и не так производительно.) Существуют API, которые утверждают, что сделали это (оба madvise () и msync ()), но они ничего на самом деле не делают.

Я не знаю о Windows, но, на UNIX, brk() вызов используется для обеспечения большей памяти в адресное пространство для использования malloc() вызовы.

Я никогда не видел эту память, возвращенную к ОС, пока процесс не завершается. Можно обычно видеть это с инструментами такой как top.

Я подозреваю, что поведение было бы тем же для Windows, но я действительно знаю, что Windows имеет другие функции выделения, чем malloc() который может сделать это (часть API Win32).

Как другой упомянутый, это более связано с malloc реализацией, чем ОС по сути. На Linux, с glibc, память на самом деле всегда возвращается к ОС выше определенного размера: glibc malloc использует mmap для больших выделений (управляемый MMAP_THRESHOLD), и в этом случае, бесплатные вызовы munmap, который освобождает автоматически зарезервированную память. Ниже того порога это использует кирпич, и свободный не "возвращает" память в этом случае.

Обратите внимание, что вышеупомянутое объяснение не точно: чтобы быть точными, необходимо знать различие между физической памятью, виртуальной памятью, и т.д... Это хорошо объяснено здесь:

http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx

Все это зависит, на которой библиотеке времени выполнения C Вы используете. Нет НИКАКОГО определенного UNIX пути или WINDOWS путь. Каждый поставщик компилятора (HP, SUN, MS, GNU) поставлется с их собственной библиотекой времени выполнения, которая содержит логику для malloc., каждая реализация malloc будет управлять тем же/отличающимся в зависимости от ОС. Никакие потребности UNIX/LINUX/Windows, что свободное "НА САМОМ ДЕЛЕ ВОЗВРАЩАЕТ" память назад ОС. Это было бы слишком дорого (начиная с Вашего выделения (), будет в очень маленьких блоках),

Недавно Mozilla Firefox одолжил malloc () реализация от *BSD ОС. Они приняли решение использовать другой malloc, чем какой их поставщик компилятора (несколько в этом случае - gcc и VC ++) поставленный. Так как они хотели определенное поведение, они получили то, что они хотели.

От этой статьи управления памятью

Malloc обычно не возвращает освобожденную память операционной системе; это остается принадлежавшим процессу, пока это не завершается. Процесс может снова использовать его в следующий раз, когда это запрашивает больше памяти, но другие программы не будут иметь доступа к нему, даже если никакая другая память не будет доступна. Как заключение, затем, объем потребляемой памяти программы является размером самого большого выделения (выделений), сделанного в любой момент. Таким образом это всегда мудро к свободным объектам, в которых Вы не нуждаетесь, особенно большие как можно скорее, для уменьшения этого места.

Та статья действительно предполагает, что в Windows, по крайней мере, для программы C, память не возвращается к ОС.

Таким образом, я не уверен в Вашем обобщении об освобождении памяти окон.

Тем не менее можно попытаться, Эмулируя управление памятью UNIX Под Microsoft Windows путем реализации низкоуровневых системных вызовов sbrk и mmap/munmap в Windows.

Обратите внимание, что я знаю намного больше о Windows, чем Unix в дальнейшем...

Что на самом деле происходит с выделением памяти, и освобождение не вполне, что Вы описываете в любом случае. Это вызвано тем, что существует два совсем других понятия на работе здесь: физическая память, которой компьютер обладает, и виртуальное адресное пространство программы, память, что Ваша программа думает, что это может использовать.

То, когда Ваша программа запрашивает больше памяти от операционной системы, что действительно происходит, - то, что ранее недоступное виртуальное адресное пространство в Вашей программе настраивается как доступное программой. Современные операционные системы не работают, просто имея пул "реальных" (то есть, физический) память, которую он раздает к процессам, когда они выполняют запрос выделения: это поддерживает виртуальное адресное пространство для каждой запускающей программы, и, когда программы на самом деле части доступа того виртуального адресного пространства, гарантирует, что это отображается на некоторой физической памяти, возможно путем выгрузки некоторой части адресного пространства другой программы к файлу подкачки на диске.

Как пример этого, в Windows каждый поток запускается с (по умолчанию) мегабайта стекового пространства, выделенного для него. Это не означает, что каждый поток использует мегабайт физической памяти машины: это просто, что адресное пространство настраивается так, чтобы это было доступно для использования. В этом смысле это действительно не работает для размышления об операционной системе, дающей память программ и затем программу, отдающую его - это просто не работает как этот.