Возврат памяти ОС

При вызове delete память возвращается в кучу.
Но что если нужно вернуть её ОС?

Например на машине 2 ГБ памяти.
Запускается программа которая сразу выделяет себе 1ГБ памяти но пользуется этой памятью только первые несколько минут после запуска. Далее программа продолжает работать но этот 1ГБ ей уже не нужен.

Получается другие программы не смогут нормально работать потому что в куче этой программы находится тот самый неиспользуемый 1ГБ?

0

да и чёрт с ними, буржуйскими программами!

0

А как насчёт решения проблемы?

0

Да что вы беспокоитесь? В политбюро не дураки сидят.
После вызова delete память может быть отдана ОС.

1

woldemas,
А можете сказать какой пункт стандарта об этом гласит?

0

Undisputed, Никакой) Всё зависит от менеджера памяти, но память обычно охотно берут и не отдают))) Если вам нужно решение, то юзайте не кучу а платформозависимые средства типа shared memory file https://msdn.microsoft.com/ru-... s.85).aspx
https://habrahabr.ru/post/122108/

0

Undisputed, Окошки тут же отдают освободившуюся память другим приложениям

1

Программа ничего не забирает у ОС и других программ. Она работает в виртуальной памяти. А операционная система сама разберётся, как распределять физическую память между различными приложениями, как откачать редко используемую память на диск и т.п.

Добавлено через 1 минуту
Проще всего найти что-нибудь и почитать про то, что такое "виртуальная память". После этого основная масса вопросов отвалится сама собой

2

Кстати, ещё флаги компиляции имеют значение.

0

Сообщение от Pechkin80 Кстати, ещё флаги компиляции имеют значение

Не имеют

0

Сообщение от DobroAlex Окошки тут же отдают освободившуюся память другим приложениям

Это зависит от сишного рантайма, не от ОС.

0

Сообщение от Братец Кролик Это зависит от сишного рантайма, не от ОС

Тут зависит исключительно от ОС и вообще ничего не зависит от Си'шного рантайма

0

gcc -Wl,--stack=xxxxx -Wl,--heap=yyyyy

0

Сообщение от Pechkin80 gcc -Wl,--stack=xxxxx -Wl,--heap=yyyyy

Это не флаги компилятора, а флаги линкера. По ним он всего лишь пропишет какие-то параметры в заголовок исполняемого файла, по которым ОС будет выделять для приложения заданное количество ВИРТУАЛЬНОЙ памяти. Это вообще никак не повлияет на то, сколько расходуется ФИЗИЧЕСКОЙ памяти. Только ОС решает, как распределять физическую память. Пользовательскому приложению это не доступно в принципе

1

Сообщение от Evg Тут зависит исключительно от ОС и вообще ничего не зависит от Си'шного рантайма

Это неверно. Когда после вызовов delete и free память станет доступной другим приложениям зависит от рантайма, а не от ОС. После какого-нибудь вызова free с точки зрения ОС на процесс может вообще ничего не измениться. Только списки свободных блоков внутри рантайма в процессе.

0

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

0

Сообщение от Undisputed Получается другие программы не смогут нормально работать потому что в куче этой программы находится тот самый неиспользуемый 1ГБ?

В ОС с виртуальной памятью все совсем не так однозначно.

* Во-первых, останется ли этот 1ГБ выделенным с точки зрения ОС зависит от поведения библиотеки времени выполнения. Грамотно реализованная библиотека времени выполнения обычно старается возвращать обратно ОС большие непрерывные куски неиспользуемой виртуальной памяти.

* Во-вторых, смогут ли нормально работать другие программы зависит от поведения и конфигурации самой ОС.

В обычной ОС, построенной на виртуальной памяти со своп-файлом (Windows, Linux) такая ситуация вообще не приведет ни к каким проблемам. Этот самый "неиспользуемый 1ГБ", именно по причине своей "неиспользуемости", будет постепенно вытолкнут из ОЗУ в своп-файл на диск и благополучно забыт. Он останется лежать на диске, никому не мешая, пока ваша программа не начнет его активно использовать. Т.е. он не будет никому мешать и вообще не будет никак ни на что влиять. Поэтому в рамках таких ОС ваше предположение о том, что "другие программы не смогут нормально работать" вообще не обоснованно. Наоборот, другие программы этого 1ГБ и не заметят.

На 64-битной платформе со своп-файлом вы можете хоть 100500ГБ навыделять - пока вы ими не пользуетесь, они просто тихо уйдут на диск и никому мешать не будут. Можно дальше сказать больше: на 64-битной платформе со своп-файлом можно вообще никогда не не освобождать память - пусть она уходит в утечки. Эти утечки никому не создадут никаких проблем, ибо будут просто тихо сбрасываться на диск, никогда больше не возвращаясь в ОЗУ, никому больше не мешая и ни на что не влияя. (Я, разумеется, ни в коем случае не призываю пользоваться этим в реальных программах.)

* Другое дело, если ваша виртуальная ОС сконфигурирована в режиме "только-ОЗУ", т.е. без своп-файла. В таком случае этот 1ГБ действительно будет сидеть в RAM и мешать другим программам. Однако для десктопных ОС такой режим работы является нештатным. А для ОС типа Android штатно рассчитанных на работу без своппинга - см. "во-первых", т.е. их библиотеки времени выполнения реализованы с учетом того, что память лучше стараться активно возвращать системе.

3

Сообщение от TheCalligrapher На 64-битной платформе со своп-файлом вы можете хоть 100500ГБ навыделять - пока вы ими не пользуетесь, они просто тихо уйдут на диск и никому мешать не будут.

Вы выделяете под своп 100500ГБ? Система "выделил 100500 ГБ и не использую" работает не через своп, а через оверкоммит. И вообще говоря, практика эта порочна, так как тянет за собой OOM killer прибивающий в случае чего кого попало.

1

Сообщение от Renji Вы выделяете под своп 100500ГБ?

Я вообще не фиксирую размер свопа. Размер свопа в данном контексте считается "неисчерпаемо астрономическим" по сравнению с моими потребностями. В любом случае, если вам в такой ситуации не хватило свопа, значит вы выделили слишком мало.

Сообщение от Renji Система "выделил 100500 ГБ и не использую" работает не через своп, а через оверкоммит. И вообще говоря, практика эта порочна, так как тянет за собой OOM killer прибивающий в случае чего кого попало.

Это - мимо кассы, ибо в данном случае речь идет о памяти, которая активно использовалась, затем была "освобождена" (с точки зрения библиотеки времени выполнения), но не возвращена ОС. Проблемы оверкоммита (если речь идет об ОС содержащих этот баг) к этому моменту уже пройдены.

1

Для полноты обсуждения не хватает рассмотрения влияния флагов компиляции. Я сам забыл уже. Когдато изучал. Помню там какаято косвенная зависимость. Но тема интересная.

1