Обсуждение:Сборка мусора
Проект «Информационные технологии» (уровень II, важность для проекта средняя)
Эта статья тематически связана с вики-проектом «Информационные технологии», цель которого — создание и улучшение статей по темам, связанным с информационными технологиями. Вы можете её отредактировать, а также присоединиться к проекту, принять участие в его обсуждении и поработать над требуемыми статьями. |
 | Эта статья была переименована по результатам обсуждения от 23 декабря 2015 года. Старое название Сборка мусора (программирование) было изменено на новое: Сборка мусора. Для повторного выставления статьи на переименование нужны веские основания, иначе такое действие будет нарушать правила (см. п. 8). |
мысли о написанном. Чего не хватает[править код]
Нет ни слова о ручном запуске сборщика мусора. Насколько это эффектмвно и насколько долго. Нет примеров по языкам программирования. Нет особенностей реализации ( кроме джавы. И то, не сообщается про то как она кольцевые ссылки детектит) про питон не сказано про гарантированное уничтожение обьектов спомощью with. Про питон также не сказано про гарантированный запуск деструктора и кничтожение обьекта после уничтожения всех ссылок. Не сказано что питон не гарантировано запускает все деструкторы при выходе приложения. То что питон для циклических ссылок с деструкторами не уничтожает обьекты вобще никогда. А также не освещена проблема выбора порядка уничтожения обьектов сфинализаторами в случае циклических ссылок. Ничего не сказано про исключения в финализаторах. Не сказано про технологию самоувеличения количества ссылок на самого себя в финализаторах. Кстати не сказано про вынужденную парадигму невалидных обьектов - ну типа обьект есть а использовать нельзя - вроде файла в питоне который для гарантии закрытия уже сделали close() но на него еще есть ссылки.
Вот за некоторые аспекты типа утечек памяти — отдельное спасибо. Впрочем среди примеров не указан более распространенный про утечку обьектов в забытых замыканиях.
Кстати еще ни слова про javascript.
Еще не рассказали хак в дельфи где исключение с сообщением о нехватке памяти выделено статически поэтому при нехватке памяти его всегда можно бросить.
Еще не сказано про невозможность реализации сборки мусора в си. Впрочем, можно упомянуть смартпоинтеры и кривую реализацию замыканий в гцц. И еще про си++ можно сказать про автоуничтожение обьектов созданных в стеке в т.ч. при возникновении исключения
Про джаву еще не сказано что она откладывает сборку до последнего пока не выест весь отведенный лимит.
79.172.14.34 21:50, 16 января 2012 (UTC)
Фрагментация памяти[править код]
На 64 битных системах эта проблема не столь актуальна. Хотя имеется тоже. Поэтому перемещающий сборщикк может только замедлить программу вместо улучшения ситуации.
Еще не написали про средства контроля ( просмотра) количества ссылок и про поиск мест откуда ссылаются на конкретный обьект.
79.172.14.34 21:55, 16 января 2012 (UTC)
Ссылочку бы про 64-х битные системы... Из вашего пояснения ситуации не совсем понятно какие проблемы фрагментации памяти решаются увеличением разрядности -- производительность фрагментированной кучи или что? И совсем не понятно каким образом 64-х битный адрес может решить такие проблемы. По-моему, должен иметь место обратный эффект: косвенным образом 64-х битный адрес увеличивает размеры выделяемых блоков. И разброс в этих размерах. Что должно приводить к повышению "стремления" кучи к фрагментации. Которая, надо думать, увеличивает время выделения/освобождения блоков памяти, и способна забивать кеш процессора свободными кусками памяти. То есть я не настаиваю на своём мнении: оно очень "на глазок" получено. Но потому и говорю: ссылочку бы... Rgo 03:06, 14 сентября 2012 (UTC)
Термин[править код]
Не понимаю, почему термин ставится под сомнение и какого вида источник нужно привести, чтобы показать, что именно сборка мусора - устоявшийся термин? Может, пару словарей по вычтехнике? РоманСузи 05:47, 31 июля 2012 (UTC)
Почему? Там же написано, потому что словарь "лингво" не согласен с таким написанием. Но лингво -- это продукт работы лингвистов, которые не знакомы с устоявшейся IT терминологией. На мой взгляд, стабильность терминологии важнее всех грамматических норм русского языка. Да и нерусского тоже. Может я не прав в этом. Но и всё же я считаю, что это так. И, уверен, большинство со мною согласится. Но есть ещё революционное меньшинство... Rgo 02:57, 14 сентября 2012 (UTC)
Просто в книгах написано именно «сборка» — но, по словарям русского языка, правильно именно «сбор». Потому это устоявшийся термин. --Mercury (обс.) 08:24, 10 мая 2017 (UTC)
Эффективность.[править код]
В статье достаточно поверхностно рассмотрен вопрос эффективности сборки мусора в сравнении с ручным управлением. На деле оказывается, что всё не столь просто.
1. Сборщик мусора может оптимизировать кучу, то есть перемещать объекты, обновляя значения указателей на эти объекты, таким образом снижая фрагментацию кучи. Это может привести (в сравнении с ручной сборкой мусора), во-первых к тому, что процесс будет использовать меньше оперативной памяти (его куча будет иметь меньше свободного места), во-вторых, что выделение памяти будет происходить быстрее, чем в случае с ручным выделением и неоптимизированной кучей (выделение сводится к инкременту указателя на первый свободный байт кучи). Об этом, кстати, хорошо в английской версии статьи написано, где они сравнивают moving vs non-moving стратегии сборки. 2. Освобождение участка памяти для системы со сборкой мусора может быть существенно более лёгкой задачей, в сравнении с "ручным" особождением. Во-всяком случае это так, когда идёт речь о конкуретном доступе к куче из разных потоков. Сборщику мусора существенно проще разрулить вопросы синхронизации. Вот ссылочка: http://www.hpl.hp.com/personal/Hans_Boehm/gc/example.html
Я бы, чесслово подправил сам, но мне в голову пока не приходит как это можно сделать "малой кровью", потому что статья вся пропитана духом _безусловной_ тормознутости и прожорливости сборки мусора. И мне не сообразить, как бы так не прерывая хода повествования и не входя в противоречия с другими частями статьи изложить иначе.
Да. И ещё может стоит просто убрать все эти глупости о несовместимости сборки мусора и непосредственной работы с указателями? Дело в том, что несовместимость, на самом деле, возникает лишь в случае moving стратегии сборки, то есть в ситуации, когда адреса объектов в памяти могут изменятся в результате выполнения очередно итерации сборки мусора. И в то же время никто не мешает прикрутить к C консервативную сборку мусора с non-moving стратегией (пример тому: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ ). Кроме того, не стоит безусловно утверждать о том, что moving сборка мусора несовместима с работой с указателями: опять же, с какой работой? Можно заглянуть, допустим, в http://www.sbcl.org/manual/Foreign-Function-Interface.html Там описан API для работы с C'шными библиотеками из sbcl (который использует moving стратегию сборки), и этот API легко оперирует понятиями "адрес", "указатель", "разадресация", делая эти понятия рабочим инструментом программиста, использующего ffi. Описывать все эти тонкости в статье, может и не стоит. Но тогда надо просто вырезать эти слова про необходимость отказа от указателя для использования сборки мусора.