не так. Допустим во время вычисления функции нам нужно было вычислить какие-то промежуточные дан-
ные, например объявленные в локальных переменных, тогда после вычисления результата все эти значения
больше не нужны. При этом в куче висит много-много объектов, которые уже не нужны. Нам нужно как-то от
них избавится. Этой задачей занимается отдельный блок вычислителя, который называется сборщиком му-
сора (garbage collector), соответственно процесс автоматического освобождения памяти называется сборкой
мусора (garbage collection или GC).
На данный момент в GHC используется копирующий последовательный сборщик мусора, который рабо-
тает по алгоритму Чейни (Cheney). Для начала рассмотрим простой алгоритм сборки мусора. Мы выделяем
небольшой объём памяти и начинаем наполнять его объектами. Как только место кончится мы найдём все
“живые” объекты, а остальное пространство памяти будем считать свободным. Как только после очередной
очистки оказалось, что нам всё же не хватает места. Мы найдём все живые объекты, подсчитаем сколько ме-
ста они занимают и запросим у системы этот объём памяти. Скопируем все живые объекты на новое место, а
старую память будем считать свободной. Так например, если у нас было выделено 30 Мб памяти и оказалось,
что живые объекты занимают 10 Мб, мы выделим ещё 10 Мб, скопируем туда все живые объекты и общий
объём памяти станет равным 40 Мб.
Мы можем оптимизировать сборку мусора. Есть такая гипотеза, что большинство объектов имеют очень
короткую жизнь. Это промежуточные данные, локальные переменные. Нам нужен лишь результат функции,
но на подходе к результату мы сгенерируем много разовой информации. Ускорить очистку можно так. Мы
выделим совсем небольшой участок памяти внутри нашей кучи, его принято называть яслями (nursery area),
и будем выделять и собирать новые объекты только в нём, как только этот участок заполнится мы скопируем
все живые объекты из яслей в остальную память и снова будем наполнять ясли. Как только вся память закон-
чится мы поступим так же как и в предыдущем сценарии. Когда заканчивается место в яслях, мы проводим
поверхностную очистку (minor GC), а когда заканчивается вся память в текущей куче, мы проводим глубокую
очистку (major GC). Эта схема соответствует сборке с двумя поколениями.
10.6 Статистика выполнения программы
Процесс управления памятью скрыт от программиста. Но при этом в GHC есть развитые средства косвен-
ной диагностики работы программы. Пока мы пользовались самым простым способом проверки. Мы вклю-
чали флаг s в интерпретаторе. Пришло время познакомиться и с другими.
Управление памятью. Сборщик мусора | 163
Статистика вычислителя
Для начала научимся смотреть статистику работы вычислителя. Посмотреть статистику можно с помо-
щью флагов s[file] и S[file]. Эти флаги предназначены для вычислителя низкого уровня (realtime system
или RTS, далее просто вычислитель), они заключаются в окружение +RTS … -RTS, если флаги идут в кон-
це строки и считается, что все последующие флаги предназначены для RTS мы можем просто написать ghc
–make file.hs +RTS … Например скомпилируем такую программу:
module Main where
main = print $ sum [1 .. 1e5]
Теперь скомпилируем:
$ ghc —make sum.hs -rtsopts -fforce-recomp
Флаг rtsopts позволяет передавать скомпилированной программе флаги для вычислителя низкого уров-
ня, далее для краткости мы будем называть его просто вычислителем. С флагом fforce—recomp программа
будет каждый раз заново пересобираться. Теперь посмотрим на статистику выполнения программы (флаг
s[file], в этом примере мы перенаправляем выход в поток stderr):
$ ./sum +RTS -sstderr
5.00005e9
14,145,284 bytes allocated in the heap
11,110,432 bytes copied during GC
2,865,704 bytes maximum residency (3 sample(s))
460,248 bytes maximum slop
7 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed)
Avg pause
Max pause
Gen
0
21 colls,
0 par
0.00s
0.01s
0.0006s
0.0036s
Gen
1
3 colls,
0 par
0.01s
0.01s
0.0026s
0.0051s
INIT
time
0.00s
(
0.00s elapsed)
MUT
time
0.01s
(
0.01s elapsed)
GC
time
0.01s
(
0.02s elapsed)
EXIT
time
0.00s
(
0.00s elapsed)
Total
time
0.02s
(
0.03s elapsed)
%GC
time
60.0%
(69.5% elapsed)
Alloc rate
1,767,939,507 bytes per MUT second
Productivity
40.0% of total user, 26.0% of total elapsed
Был распечатан результат и отчёт о работе программы. Разберёмся с показателями:
bytes allocated in the heap
— число байтов выделенных в куче
— за всё время работы программы
bytes copied during GC
— число скопированных байтов
— за всё время работы программы
bytes maximum residency
— в каком объёме памяти работала программа
— в скобках указано число глубоких очисток
bytes maximum slop
— максимум потерь памяти из-за фрагментации
total memory in use
— сколько всего памяти было запрошено у ОС
Показатель bytes maximum residency измеряется только при глубокой очистке, поскольку новая память
выделяется именно в этот момент. Размер памяти выделенной в куче гораздо больше общего объёма памяти.
Так происходит потому, что этот показатель указывает на общее число памяти в куче за всё время работы
программы. Ведь мы переиспользуем не нужную нам память. По этому показателю можно судить о том,