Введенние.
Zval.
Циклические ссылки.
Сборщик мусора.
Алгоритм работы сборщика мусора.
Смотрим глазами.
Слабые ссылки.
Бонус-трэк: WeakMap.
Заключение.
В PHP память для всех наших переменных выделяется динамическиЧитать полностью »
Эта статья написана в основном для системных администраторов Java-приложений (DevOps-инженеров, SRE и других производных специализаций). Вероятнее всего, Java-разработчики уже все это прекрасно знают. Хотя Junior Java-разработчикам эта информация может помочь систематизировать знания.
Каждый экземпляр класса в CPython, созданный при помощи синтаксической конструкции class, участвует в механизме циклической сборки мусора. Это увеличивает след в памяти каждого экземпляра и может создавать проблемы с памятью в высоконагруженных системах.
Нельзя ли обойтись в случае необходимости одним базовым механизмом подсчета ссылок?
Разберем один подход, который поможет создавать классы, чьи экземпляры будут удаляться только с помощью механизма подсчета ссылок.
Как правило, вам не нужно беспокоиться о сборщике мусора и работе с памятью когда вы пишите код на Python. Как только объекты больше не нужны, Python автоматически освобождает память из под них. Несмотря на это, понимание как работает GC поможет писать более качественный код.
В отличие от других популярных языков, Python не освобождает всю память обратно операционной системе как только он удаляет какой либо объект. Вместо этого, он использует дополнительный менеджер памяти, предназначенный для маленьких объектов (размер которых меньше чем 512 байт). Для работы с такими объектами он выделяет большие блоки памяти, в которых в дальнейшем будет хранится множество маленьких объектов.
Как только один из маленьких объект удаляется — память из под него не переходит операционной системе, Python оставляет её для новых объектов с таким же размером. Если в одном из выделенных блоков памяти не осталось объектов, то Python может высвободить его операционной системе. Как правило, высвобождение блоков случается когда скрипт создает множество временных объектов.
Читать полностью »
В последнее время мне встречалось немало статей, в которых не самым удачным для меня образом продвигается свежий сборщик мусора в Go. Некоторые из статей написали разработчики самого языка, и их утверждения намекали на радикальный прорыв в технологии сборки мусора.
Вот первичный анонс о внедрении нового сборщика, датированный августом 2015-го:
В Go создаётся сборщик мусора (GC) не только для 2015 года, но и для 2025-го, и ещё дальше… Сборщик в Go 1.5 возвещает о наступлении будущего, в котором паузы на сборку больше не являются барьером для перехода на безопасный язык. Это будущее, в котором приложения без труда масштабируются вместе с оборудованием, и по мере роста мощности оборудования сборщик мусора больше не является сдерживающим фактором при создании более качественного, масштабируемого ПО. Go — хороший язык для использования как минимум в ближайший десяток лет.
Создатели утверждают, что они не просто решили проблему пауз на сборку мусора, а пошли куда дальше:
Одним из высокоуровневых способов решения проблем с производительностью является добавление GC-настроек (knobs), по одной на каждую проблему. Программист может менять их, подбирая наилучшую комбинацию для своего приложения. Недостатком этого подхода является то, что при внедрении каждый год одной-двух новых настроек через десять лет придётся законодательно регулировать труд людей, которые будут менять эти настройки. Go не пошёл по этому пути. Вместо кучи настроек мы оставили одну и назвали её GOGC.
Более того, освободившись от бремени поддержки десятков настроек, разработчики могут сосредоточиться на улучшении runtime’а приложения.
Не сомневаюсь, что многие пользователи Go были просто счастливы получить новый подход к runtime’у в Go. Но у меня есть претензии к этим заявлениям: они выглядят как недостоверный маркетинговый булшит. А поскольку они раз за разом воспроизводятся в Сети, пришло время подробно с ними разобраться.
Читать полностью »
Большинство разработчиков воспринимают сборку мусора (garbage collection) как нечто само собой разумеющееся. Это стандартный процесс, который периодически освобождает память, удаляя ненужные объекты. А вот американский программист Кен Фокс (Ken Fox) захотел досконально разобраться и заглянуть «под капот» современных сборщиков мусора.
Кен «поигрался» с пятью разными алгоритмами сборки мусора и опубликовал маленькие анимации, которые наглядно демонстрируют их работу.
Анимации большего размера выложены на github.com/kenfox/gc-viz.
Читать полностью »
Эта поучительная история повествует о том, как важно развивать навыки гугления, и о том, как я боролся с ежечасным полным Garbage collection.
После того, как мы мигрировали в продакшене один из компонентов системы (единственный, работающий на Tomcat) на новую версию томката, неожиданно саппорт запаниковал, увидев в логах полуторасекундные запуски GC.
Читать полностью »
16-я версия браузера Firefox, релиз которй намечен на 9 октября, содержит серьёзное обновление движка JavaScript. Сборщик мусора перейдёт от стратегии «stop-the-world», когда на время уборки полностью замораживается работа скриптов, к инкрементальной стратегии, когда сборка мусора происходит в несколько этапов. Хотя в целом работа сборщика мусора будет отнимать немного больше времени, отзывчивость браузера существенно улучшится, так как элементы интерфейса, анимация и игры не будут больше подвисать на несколько сотен миллисекунд на время уборки.
Читать полностью »
Для незнакомых с этой очень интересной тематикой советую посмотреть обзор на вики. Для более полного понимания проблемы: детальный обзор у Кнута в 1 томе Искусство программирования в разделе 2.5 Динамическое выделение памяти, на хабре, а также одну из лучших реализаций на C/C++ Hans Boehm.
Сразу оговорюсь, предлагаемый мною подход принципиально отличается от вышеизложенных и основан на реализации ООП в C++. В топики приведено описание готовой библиотеки и ссылка на исходники.
Читать полностью »
