?

Log in

программистское: о памяти - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

программистское: о памяти [ноя. 22, 2009|12:04 am]
Anatoly Vorobey
В обсуждении о компиляторах всплыл полезный совет: иногда об освобождении памяти лучше и не думать.
Memory leaks are the least of your problems in a compiler; it's not like it's a long running process. You run it, it terminates, the OS cleans up for you.
I did some work on SDCC years ago and it went through a brief "lets use a garbage collector!" phase until everybody realized it was contributing negative value. It was more efficient to simply free memory where convenient and leak it where not.

... и дальше:

I believe it's well known that compilers leak memory like sieves. But the thing is, it doesn't really matter in most contexts. If the leak is linear with the size of the program you're probably fine and no one will notice anyway.


(кстати, всю эту дискуссию о компиляторах стоит проглядеть: там есть немало отличных ссылок)

Это очень полезный совет: иногда в языке и среде, которые казалось бы требуют тщательной работы с malloc()/free() или их эквивалентами, про free() можно просто забыть и не делать, если программа выполняется быстро и не требует очень много памяти. Полезный потому, что привыкший к тщательной дисциплине программист может об этом просто не подумать.

Но мне это напомнило еще вот какую давнюю мысль: по-моему, намного реже, чем следовало бы, программисты на языках с эксплицитной обработкой памяти пользуются отдельными кучами. "Отдельная куча" (private heap) означает всего лишь возможность отводить память в отдельном месте, идентифицируемом каким-то ключом. Например, в Win32 есть функции: HeapCreate() создает новую кучу и возвращает идентификатор, HeapAlloc() - вместе с желаемым размером получает идентификатор кучи и отводит память именно в ней, HeapFree() - очевидно, и HeapDestroy() - удалить всю кучу вместе со всей памятью в ней, которой еще не сделали HeapFree().

Иногда это называют не кучей, а "ареной", но суть та же. На самом деле самое главное во всем этом - возможность удалить кучу одним махом, потому что если она есть, и если вся память, что отводится из кучи, вместе не слишком велика, то отдельно освобождать ничего не надо. Собственно, можно обойтись без free() вообще. Куча тогда превращается в сплошной кусок памяти (или связанный список таких кускок, если надо), а malloc() становится тривиальным, он просто двигает указатель на свободную часть кучи.

Очень часто значительная часть логики программы устроена так. Начинаем строить какой-то объект (в C это может быть сложная структура, неважно), он в свою очередь создает и инициализирует другие объекты внутри себя, или целые массивы, или списки, или еще что, неважно. Все это по цепочке вложено друг в друга, а после создания еще начинает как-то работать и двигаться вместе, вызывать друг друга, хранить какую-то информацию итд. В конце концов объект выполнил свое дело и удаляется, по цепочке вначале удаляя все вложенные объекты и контейнеры и освобождая всю память. Все это делается через сложный танец new/delete или malloc/free. Но если вся память, что нужна объекту и всему, что в него вложено, не слишком велика на протяжении его жизни, то с помощью отдельной кучи только для этого объекта и всего, что в него вложено, можно избежать всего этого сложного танца и сделать код одновременно намного проще, лучше защищенным от ошибок и даже быстрее - да-да, быстрее, чем обычный танец malloc/free. Единственное, чем платишь - повышенным расходом памяти во время жизни объекта, да и то часто налог этот весьма невелик.

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

Comments:
[User Picture]From: _navi_
2009-11-21 10:20 pm
А чем конкретно полезно это специфичное WinAPI для использования арен? Тем, что за тебя уже определён какой-то кастомный HeapAlloc, который наверняка содержит в себе что-то лишнее для данной проблемы, как минимум работу с фри-листами (вместо того, чтобы дать программисту возможность задать оптимальный алгоритм аллокации для арены)?
(Ответить) (Thread)
[User Picture]From: avva
2009-11-21 11:01 pm
Полезно в первую очередь тем, что оно есть и стандартное, и тем самым привлекает внимание программиста, становится частью его стандартного арсенала итд.

То, что HeapAlloc() использует свой конкретный алгоритм, и в частности не так быстр, как, например, алгоритм сплошной аллокации без освобождения - в 99.99% случаев абсолютно неважно и никакой роли не играет. Давайте не забывать слова Кнута о преждевременной оптимизации.
(Ответить) (Parent) (Thread) (Развернуть)
From: (Anonymous)
2009-11-21 10:38 pm
Мне нравится что я понимаю о чем ты говоришь. Я начал изучать C/С++ нерегулярно и для себя, непрограммиста (вернее в далеком прошлом).
Как не крути это высокая поэзия (разговоры о распределении памяти), хотя, видимо программирование уже давно ремесло.
Вообщем, мы все умрем:)
(Ответить) (Thread)
[User Picture]From: egorfine
2009-11-21 10:52 pm
Сейчас программирую под айфон - приходится очень внимательно относиться к памяти. Даже местный memory manamement в objc не спасает, надо ручками. Всего 128 мег памяти, из них приложению доступно в самый максимум сто мег.
(Ответить) (Thread)
[User Picture]From: avva
2009-11-21 10:59 pm
Вы почитайте вот, вдохновитесь:

http://jordanmechner.com/wp-content/uploads/1989/10/popsource009.pdf

Особенно стр. 4 этого документа. Это к вопросу о "максимум сто мег".
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: izblank
2009-11-21 11:13 pm
Мы сейчас похожую стратегию к нашей базе данных думаем применить. Вместо того, чтобы заботиться о партициях, foreign keys, и прочих заморочках, просто посылать все новое в другую базу, а старую по происшествии какого-то времени дропнуть, и все дела. И так каждый год.
(Ответить) (Thread)
[User Picture]From: glex1
2009-11-23 12:32 am
А мы просто запускаем очистку db от мусора раз в месяц
(Ответить) (Parent) (Thread) (Развернуть)
From: (Anonymous)
2009-11-21 11:35 pm
Как не профи я все-таки не понимаю, почему бы os не чистить автоматически то что было сделано приложением. Такой большой брат следит за всеми malloc/new и потом все чистит.Есть что-то невозможное в этом?
(Ответить) (Thread)
From: (Anonymous)
2009-11-22 12:26 am
Она и чистит. По завершению процесса.
До завершения она ведь не знает, когда именно что можно очистить.
(Ответить) (Parent) (Thread)
From: (Anonymous)
2009-11-22 12:47 am
Хорошо, запустили процесс, определили для процесса предельные величины использования памяти, типа, всего допустимой для выделения памяти/кол-во процессов. Дальше нужно os должна следить не за абсолютными величинами, а за динамикой и new - вдруг программер ошибся, возвращает указатели на аллоокированные куски из процедуры и т.д. можно придумать некие предыгадывающие механизмы, которые говорили бы os что девелопер ох..л или прога неправильно работает. По-моему, кол-во таких ситуаций конечно.
(Ответить) (Thread)
[User Picture]From: avva
2009-11-22 01:17 am
Есть утилиты для отладки, которые именно так работают: следят за динамикой итд. Операционной системе в целом нет смысла этим заниматься, потому что она ничего интересного о приложении не знает, и ничего с ним не может сделать, кроме как убить; но если там какой-то баг или память сильно протекает, оно скорее всего и так произойдет. А если бы ОС на основании динамики выделения памяти пыталась убить приложение, то поубивала бы неизбежно кучу легитимных приложений с необычной динамикой памяти.
(Ответить) (Parent) (Thread)
[User Picture]From: msh
2009-11-22 01:11 am
Memory leaks are the least of your problems in a compiler; it's not like it's a long running process. You run it, it terminates, the OS cleans up for you.

недавний пост одного из моих friends

Сборка libtorrent-rasterbar 0.14.6 уложила мне виртуальную машину, run out of swap space. Гиг памяти и гиг свопа.
(Ответить) (Thread)
[User Picture]From: avva
2009-11-22 01:14 am
Это почти наверняка линкер (или он запустил слишком много параллелизации).
(Ответить) (Parent) (Thread) (Развернуть)
From: 9000
2009-11-22 01:43 am
Что до раздельных куч, то этот приём активно применялся, помнится, в Doom. Как раз для быстрой очистки всех ненужных объектов.
А ещё в древнем паскале (не помню версии, может, это ещё от Вирта идёт) для кучи были процедуры mark и release. Говоришь mark, делаешь какие хошь аллокации, говоришь release, куча сдувется обратно до состояния на момент mark. Но с раздельными удобнее.
(Ответить) (Thread)
From: vakhitov
2009-11-22 11:32 am
В TP 3.x вроде было?
(Ответить) (Parent) (Thread)
From: ext_183539
2009-11-22 04:16 am
Это все правда, но не надо забывать, что такой подход - не серебряная пуля. Кромен памяти еще и другие ресурсы есть, которые тоже надо освобождать.
(Ответить) (Thread)
[User Picture]From: avva
2009-11-22 05:36 am
Интересно, а серебряные пули вообще бывают, ну буквально то есть? Серебро не слишком ли мягкий металл для пули? (может, я несу бред - я в этом ничего не понимаю)
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: rxvm
2009-11-22 04:59 am
4G памяти - это на самом деле очень мало. Я сталкивался с тем, что некий нехорошиий (сгенерированный) С-код в несколько сотен строк крешится на некоторых уважаемых компиляторах из-за нехватки 32-битного адресного пространства.

Память, в отличие от run-time, плохо масштабируется: в какой-то момент уже небольшой рост приводит к тому, что процесс падает или уходит в свап. Это, в частности, одна из проблем в model checking: ты можешь согласиться с тем, чтобы ждать недели, пока экспоненциальный алгоритм даст тебе ответ, но с экспоненциального размера моделью просто невозможно работать.

Private heap - хорошая штука.
(Ответить) (Thread)
From: (Anonymous)
2009-11-22 05:08 am
Кому надо, делает не на коленке, а на столе, как человек :)

Например, в рантайме апача имеется соответствующая подсистема. В веб-сервере (и в любом stateless сервере) это единственная разумная стратегия работы с памятью. Память, связанная с запросом, живет не дольше, чем сам запрос. В апаче все еще несколько удобнее: пул может быть частью другого пула. Можно прибить пул и вместе с ним освобождаются все его дети. А освобождение кусков внутри пула не предусмотрено, ибо незачем.

Пы. Сы. В Калифорнийщину по поводу Хрома ездили?
(Ответить) (Thread)
[User Picture]From: avva
2009-11-22 05:19 am
Да, вебсервер - почти идеальная модель для такой работы с памятью.

Нет, я не работаю над Хромом и ездил не за этим.
(Ответить) (Parent) (Thread)
[User Picture]From: shure
2009-11-22 07:36 am
Неужели нет такой GLPL library ? Если нет - давайте делать.
Несколько лет назад я вставил BoehmGC в большой коммерческий проект. Вот несколько результатов:
1) С тех пор, я отлаживаю все memory leaks в фирме.
2) С тех пор, я отлаживаю все memory corruptions в фирме (что хуже!).
3) Каждый раз отлаживая все это я очень опасаюсь обнаружить реально тежёлую проблему с Boehm. Вынуть то его нельзя! Нервы-ж знаете не железные.
Так что решение с private heaps кажется мне отличным компромиссом для многих случаев.
(Ответить) (Thread)
[User Picture]From: vitus_wagner
2009-11-22 07:46 am
Как нету? Apache Portable Runtime. Она, правда, Apache License, а не GPL, но хрен ли разницы.
(Ответить) (Parent) (Thread)
[User Picture]From: a_p
2009-11-22 01:16 pm
мне кажется, что введение дополнительного уровня в иерархии аллокаций (то есть приватных хипов) в Виндоус и отсутствие его же в Юниксе как-то связано с тем, что в Юниксе многие проблемы решаются заведением отдельных процессов (то есть, "эквивалент" отдельного хипа имеет вид - завели процесс, поработали-поаллокировали, потом убили с высвобождением памяти), в Виндоус же процесс тяжелее, откуда (в том числе) и треды стали гораздо нужнее. Кстати, довольно важное преимущество использования множественных хипов под Виндоус - в том, что их можно заводить потредно, а это позволяет не сериализировать работу с выделением/освобождением памяти из хипа.
(Ответить) (Thread)
[User Picture]From: kmmbvnr
2009-11-23 05:54 am
А по факту, в unix, кто кроме web приложений и shell скриптов кто так поступает?

(Ответить) (Parent) (Thread) (Развернуть)
From: (Anonymous)
2009-11-22 04:18 pm
>>Но если вся память, что нужна объекту и всему, что в него вложено, не слишком велика на протяжении его жизни, то с помощью отдельной кучи только для этого объекта и всего, что в него вложено, можно избежать всего этого сложного танца и сделать код одновременно намного проще, лучше защищенным от ошибок и даже быстрее - да-да, быстрее, чем обычный танец malloc/free

Это наверно не подойдет для того случая,когда обьект создавался другим программистом.Как я смогу узнать размер памяти необходимой для работы обьекта если я его не создавал?
(Ответить) (Thread)
[User Picture]From: cmm
2009-11-22 04:23 pm
а кто-то сказал что размер той отдельной кучи ограничен?  время её жизни ограничено, только и всего.
(Ответить) (Parent) (Thread)
[User Picture]From: kmmbvnr
2009-11-23 05:48 am
Да, наверное просто имеет смысл использовать раздельные кучи для повышения живучести документоориентированного приложения. Каждый документ в отдельную кучу, где-то во время работы конечно придется память чистить, но при закрытии документа гарантированно отчищать все.
(Ответить) (Thread)
[User Picture]From: plakhov
2009-11-23 08:11 am
Мы сотоварищи довольно большой memory-bound проект написали полностью на аренах. Я был очень доволен. Здесь в комментариях звучали слова "максимум сто мег", у нас было максимум три.

Особенно мне нравилось даже не "отсутствие утечек" (по-моему, для опытного программиста это все-таки никогда не проблема), а доказательность всего кода, скорость операций с памятью и красота реализации weak reference'ов, без каких-либо tradeoff'ов.

Если интересно про weak reference'ы и стратегию освобождения памяти, не противоречащую этим идеям: http://plakhov.livejournal.com/77787.html
(Ответить) (Thread)
[User Picture]From: laformica
2009-11-23 07:27 pm
Вот подумалось, а интересно, если взять набор типовых алгоритмов и померять производительность и расход памяти в случае реализации на языке c GC и без, но с аренами, какие результаты будут?
(Ответить) (Thread)