The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Сборка мусора (memory )


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: 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: [email protected] (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 [email protected] II:LDXIII/MCMLXXII.CCC --- ifmail v.2.15dev5 * Origin: Lucky Netch Incorporated (2:5020/400)

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру