Начальный размер "кучи", выделенный программе C++ на UNIX

Для C ++, независимо от платформы, куча почти всегда расширяется динамически, запрашивая у ОС больше памяти по мере необходимости. На некоторых встроенных платформах или некоторых очень старых платформах это может быть неправдой, но тогда вы, вероятно, имеете действительно хорошее представление о том, сколько у вас кучи из-за природы среды.

На платформах Unix это вдвойне верно. Даже большинство встроенных платформ Unix работают таким образом.

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

В большинстве систем Unix существует жесткое ограничение на общий объем памяти, который может иметь процесс. Это ограничение можно запросить с помощью системного вызова getrlimit . Соответствующая константа - RLIMIT_AS. Этот предел определяет максимальное количество страниц памяти, которое может быть назначено процессу, и напрямую ограничивает объем доступного пространства кучи.

К сожалению, этот предел не говорит напрямую, сколько кучи вы можете использовать. Страницы памяти назначаются процессу в результате вызовов mmap для хранения самого программного кода и для стека процесса.

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

Наконец, некоторые версии Unix чрезмерно назначают страницы. Они позволяют выделять огромное количество страниц, но на самом деле находите память для этих страниц только тогда, когда вы пишете на них. Это означает, что ваша программа может быть остановлена ​​из-за нехватки памяти, даже если все вызовы выделения памяти завершатся успешно. Обоснованием этого является возможность выделять огромные массивы, которые будут использоваться только частично.

Итак, короче говоря, нет типичного размера и нет хорошего способа узнать, какой размер на самом деле.

Куча расширяется динамически, запрашивая у ОС больше памяти по мере необходимости.

Это определяется не компилятором, а библиотекой.

Это более типично для исправить размер кучи в динамических языках с помощью GC. В C и C ++ просто запросить у ОС больше памяти, так как это очевидно, когда вам это нужно. Как следствие, начальный размер кучи имеет очень мало значения и является всего лишь решением реализации со стороны библиотеки распределения.

Короче говоря, не существует определенного способа настроить размер кучи. Но у нас есть способ повлиять на размер памяти кучи, поскольку размер памяти кучи является частью общей доступной памяти.

Вы можете получить общий объем доступной памяти в системе следующим образом:

 cat /proc/meminfo  | grep CommitLimit 
 CommitLimit:    498080 kB

Этот CommitLimit рассчитывается по следующей формуле: CommitLimit = ('vm.overcommit_ratio' * Physical RAM) + Swap

Предположим, что swap равен нулю, установив overcommit_ratio , вы можете настроить общий объем доступной памяти. Вы можете установить overcommit_ratio с помощью :

sysctl -w vm.overcommit_ratio=60

. И важно отметить, что этот предел соблюдается только в том случае, если включен строгий учет избыточного количества данных (режим 2 в 'vm.overcommit_memory'). . Это может быть установлено следующим образом:

 sysctl -w vm.overcommit_memory=2

Вот документ ядра , который хорошо это объясняет.

вы можете попробовать написать небольшую программу с циклом while (true). после запуска "cat / proc / {pid} / maps" вы узнаете его начальный размер кучи.