Обсуждение:Сборка мусора

message: Нет ни слова о ручном запуске сборщика мусора. Насколько это эффектмвно и насколько долго. Нет примеров по языкам программирования. Нет особенностей реализации ( кроме джавы. И то, не сообщается про то как она кольцевые ссылки детектит) про питон не сказано про гарантированное уничтожение обьектов спомощью with. Про питон также не сказано про гарантированный запуск деструктора и кничтожение обьекта после уничтожения всех ссылок. Не сказано что питон не гарантировано запускает все деструкторы при выходе приложения. То что питон для циклических ссылок с деструкторами не уничтожает обьекты вобще никогда. А также не освещена проблема выбора порядка уничтожения обьектов сфинализаторами в случае циклических ссылок. Ничего не сказано про исключения в финализаторах. Не сказано про технологию самоувеличения количества ссылок на самого себя в финализаторах. Кстати не сказано про вынужденную парадигму невалидных обьектов - ну типа обьект есть а использовать нельзя - вроде файла в питоне который для гарантии закрытия уже сделали  close() но на него еще есть ссылки.
Вот за некоторые аспекты типа утечек памяти — отдельное спасибо.  Впрочем среди примеров не указан более распространенный про утечку обьектов в забытых замыканиях.
Кстати еще ни слова про javascript.
Еще не рассказали хак в дельфи где исключение с сообщением о нехватке памяти выделено статически поэтому при нехватке памяти его всегда можно бросить. 
Еще не сказано про невозможность реализации сборки мусора в си. Впрочем, можно упомянуть смартпоинтеры и кривую реализацию замыканий в гцц. И еще про си++ можно сказать про автоуничтожение обьектов созданных в стеке в т.ч. при возникновении исключения
Про джаву еще не сказано что она откладывает сборку до последнего пока не выест весь отведенный лимит.
79.172.14.34 21:50, 16 января 2012 (UTC)
thread_title:  мысли о написанном. Чего не хватает 

message: На 64 битных системах эта проблема не столь актуальна. Хотя имеется тоже. Поэтому перемещающий сборщикк может только замедлить программу вместо улучшения ситуации.
Еще не написали про средства контроля ( просмотра) количества ссылок и про поиск мест откуда ссылаются на конкретный обьект. 
79.172.14.34 21:55, 16 января 2012 (UTC)
Ссылочку бы про 64-х битные системы... Из вашего пояснения ситуации не совсем понятно какие проблемы фрагментации памяти решаются увеличением разрядности -- производительность фрагментированной кучи или что? И совсем не понятно каким образом 64-х битный адрес может решить такие проблемы. По-моему, должен иметь место обратный эффект: косвенным образом 64-х битный адрес увеличивает размеры выделяемых блоков. И разброс в этих размерах. Что должно приводить к повышению "стремления" кучи к фрагментации. Которая, надо думать, увеличивает время выделения/освобождения блоков памяти, и способна забивать кеш процессора свободными кусками памяти. То есть я не настаиваю на своём мнении: оно очень "на глазок" получено. Но потому и говорю: ссылочку бы... Rgo 03:06, 14 сентября 2012 (UTC)
thread_title:  Фрагментация памяти 

message: Не понимаю, почему термин ставится под сомнение и какого вида источник нужно привести, чтобы показать, что именно сборка мусора - устоявшийся термин? Может, пару словарей по вычтехнике? РоманСузи 05:47, 31 июля 2012 (UTC)
Почему? Там же написано, потому что словарь "лингво" не согласен с таким написанием. Но лингво -- это продукт работы лингвистов, которые не знакомы с устоявшейся IT терминологией. На мой взгляд, стабильность терминологии важнее всех грамматических норм русского языка. Да и нерусского тоже. Может я не прав в этом. Но и всё же я считаю, что это так. И, уверен, большинство со мною согласится. Но есть ещё революционное меньшинство... Rgo 02:57, 14 сентября 2012 (UTC)
Просто в книгах написано именно «сборка» — но, по словарям русского языка, правильно именно «сбор». Потому это устоявшийся термин. --Mercury (обс.) 08:24, 10 мая 2017 (UTC)
thread_title:  Термин 

message: В статье достаточно поверхностно рассмотрен вопрос эффективности сборки мусора в сравнении с ручным управлением. На деле оказывается, что всё не столь просто.
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. Описывать все эти тонкости в статье, может и не стоит. Но тогда надо просто вырезать эти слова про необходимость отказа от указателя для использования сборки мусора.
Rgo 08:00, 13 сентября 2012 (UTC)
thread_title:  Эффективность.