Начальный размер кучи, выделенный программе C ++ в UNIX - PullRequest
5 голосов
/ 12 октября 2009

Какой начальный размер кучи обычно выделяется для программы на C ++, работающей в ОС UNIX?

Как это решается компилятором g ++, если он вообще играет какую-то роль в этом отношении?

Ответы [ 4 ]

5 голосов
/ 12 октября 2009

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

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

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

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

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

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

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

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

4 голосов
/ 12 октября 2009

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

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

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

0 голосов
/ 12 октября 2009

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

0 голосов
/ 12 октября 2009

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

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

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

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

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

sysctl -w vm.overcommit_ratio=60

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

 sysctl -w vm.overcommit_memory=2

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

...