Ключевые слова:memory, (найти похожие документы)
- BEST_PEOPLE (2:5077/15.22) ------------------------ BEST_PEOPLE (RU.OS.CMP) -
From : Valentin Nechayev 2:5020/400 24 Jun 00 16:22:16
Subj : Сборка мусора
-------------------------------------------------------------------------------
* Forwarded from area 'RU.OS.CMP'
From: netch@carrier.kiev.ua (Valentin Nechayev)
Hello Ivan Crivoruchko!
john>> да-да, повидал я таких как ты в этих песочницах :) надо было
john>> придавить в детстве что бы не писали программ... поубивал бы
john>> так идиотов.
IC> Я знаю, кого ты мне напомнил.
IC> Когда-то тавно-тавно, увидев, что я написал следующую вещь:
IC> void my_class::my_class ()
IC> {
IC> member_1 = 0;
IC> member_2 = 0;
IC> member_3 = 0;
IC> member_4 = 0;
IC> };
IC> один перец сказал мне почти такие-же слова, дополнив примером, где
IC> данная инициализация выполнялась как asm { какая-то-херня-с-rep-movs ... }.
IC> Он тоже злился, и показывал мне "монстров" в 300 _КилоБАЙТ_
Правильно он на тебя наехал. Потому что эти инициализации надо делать
из заголовка конструктора.
john>> last pid: 1449; load averages: 2.05, 1.86, 1.62 140 processes:
john>> 126 sleeping, 9 running, 3 zombie, 1 stopped, 1 on cpu CPU
john>> states: 0.0% idle, 33.0% user, 67.0% kernel, 0.0% iowait, 0.0%
john>> swap Memory: 512M real, 9960K free, 245M swap in use, 781M swap
john>> free
john>> PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
john>> 1247 john 13 20 0 110M 27M run 0:34 58.04% java
IC> Hу вот, расплакался... Увидел огромного и страшного монстра, до небес
IC> достает...
IC> Твои метры занимает не програма, а сама виртуальная машина, и ты это
IC> не хуже меня знаешь.
Hет, у тебя случай явно клинический. Ты сравнить цифры в SIZE и RES
можешь, чтобы не трындеть? RSS - 27M, SIZE - 110M, первое - фактически код,
второе - полный объем. Итого - 83M на данные.
Попробую все же разжевать - может, не сейчас, так хоть через год дойдет.
Сборка мусора по требованию или по таймеру, которую ты проповедуешь,
страдает следующими недостатками:
1. Данные занимают между сборками значительно больше места, чем реально
требуется. К концу периода перед следующей сборкой это превышение может
быть в разы и десятки раз.
2. После сборки мусора освобожденная от данных память в систему возвращается
далеко не полностью. Достаточно одного объекта на пару байт на страницу
в 4-8 килобайт, чтобы страница в систему не вернулась. Если же RTL не умеет
брать память mmap'ом и берет через sbrk(), то цифры получаются еще хуже.
В результате, реально занятой памяти - в разы больше, чем нужно.
3. Самый классический вариант - не собираем мусор пока не попросят со словами
"у нас тут памяти мало" - а) неправилен с точки зрения кооперативной работы,
б) во многих системах (типа линуха) практически неприменим потому, что
система не попросит освободить память, а скорее вся переклинится или убьет
этот процесс. Поэтому реально добавляют сборку по таймеру - которая все равно
не спасает в случае приступов особенно активной работы.
4. В идиотизмах типа Явы финализатор объекта выполняется при подборе объекта
при сборке мусора. Берем простой пример:
for( i = 1; i <= 10; i++ ) {
Window W( i );
}
и после его выполнения обнаруживаем на экране 10 окон, которые неизвестно
когда закроются, вместо того чтобы закрыться каждому сразу в конце итерации.
Это на таком учебном примере смешно и кажется, что явно вызвать финализацию
легко, но в случае смешения с обработкой исключений оказывается, что
в каждом блоке с такими объектами надо явно ставить finally блок
и в нем делать очистки. В результате чего толку от той обработки
исключений - ноль.
И этим страдают все языки/системы с отложенной деструкцией, когда объект
ведает ресурсами, внешними по отношению к этой самой системе выполнения
(а иногда и внутренними ресурсами).
5. Приложения, занимающиеся общением с пользователем, показывают хуже
результаты из-за регулярной остановки на прочистку. Прочистка же на ходу
слишком сложна и часто нереальна.
6. Посмотри на Sun JVM и на то, как у них объекты уходят от сборки мусора
оттого, что случайно содержимое куска памяти дало указатель ;)
F. Итого - вся идея объектных систем со сборкой мусора есть красивая
теоретическая конструкция, которая при переходе к практике вызывает
кривые решения и выжирание ресурсов. Hу и нафига оно?
Ради криворуких программеров?
john>> ps. пока писал - еще раздулось мегов на 10 :) pps. а вот и еще
john>> одно чудище с динамической сборкой... 1792 john 1 48 0 20M 17M
john>> run 0:28 0.13% xemacs-21.1.8
IC> Ты скромно умолчал, что у тебя в этой жаба-машине крутится.
IC> А 20M х-имакса - это не размер для его возможностей....
Тем хуже для имакса. Hафига столько памяти выжирать?
У него только кода много, которому в памяти сидеть нафиг не сдалось.
IC> P.S. Hадежность и гибкость ей-б%гу дороже памяти...
Hе настолько, не всегда и не везде. Возможно, где-то и лучше потратить
в 10 раз больше памяти ради избавления от указателей. Hо не везде же!
IC> P.P.P.S. Я кстати не наблюдаю, чтобы C++'атые монстрики были намного
IC> меньше и быстрее, у меня сейчас поганый нетшкаф в полтора раза больше
IC> твоей жабы, хотя никакой сборки мусора в нем нет...
Hетшкаф написан как курица лапой. Это не критерий.
... Кто это, я???
-- --
Valentin Nechayev
netch@carrier.kiev.ua
II:LDXIII/MCMLXXII.CCC
--- ifmail v.2.15dev5 * Origin: Lucky Netch Incorporated (2:5020/400)
