Введенние.
Zval.
Циклические ссылки.
Сборщик мусора.
Алгоритм работы сборщика мусора.
Смотрим глазами.
Слабые ссылки.
Бонус-трэк: WeakMap.
Заключение.
В PHP память для всех наших переменных выделяется динамическиЧитать полностью »
В рамках мер повышения рентабельности наша команда недавно занялась снижением затрат на вычислительные мощности посредством увеличения их эффективности. Один из самых значимых вкладов был внесён в области оптимизации GOGC. В этом посте мы хотим поделиться высокоэффективным, малоопасным, крупномасштабным полуавтоматизированным механизмом настройки сбора мусора в Go.
Технологический стек Uber состоит из тысяч микросервисов на базе нативной облачной архитектуры на основе планировщика. Большинство этих сервисов написано на Go. Наша команда Maps Production Engineering ранее сыграла важную роль в значительном повышении эффективности множества сервисов Java при помощи настройки сборки мусора. В начале 2021 года мы исследовали возможности достичь такого же эффекта в сервисах на Go. Мы запустили несколько профилей CPU для оценки текущего состояния дел и выяснили, что сборка мусора была главным потребителем ресурсов CPU в подавляющем большинстве критически важных сервисов. Ниже приведено описание некоторых профилей CPU, в которых сборка мусора (определяемая объектом runtime.scanobject) потребляет значительную долю выделенных вычислительных ресурсов.
Читать полностью »
В прошлом году Mozilla выпустила Quantum CSS для Firefox, который стал кульминацией восьми лет разработки Rust — безопасного для памяти языка системного программирования. Потребовалось более года, чтобы переписать основной компонент браузера на Rust.
До сих пор все основные браузерные движки написаны на C++, в основном по соображениям эффективности. Но с большой производительностью приходит большая ответственность: программисты C++ должны вручную управлять памятью, что открывает ящик Пандоры уязвимостей. Rust не только устраняет такие ошибки, но его методы также предотвращают гонки данных, позволяя программистам более эффективно внедрять параллельный код.
Менеджмент, тестирование и фронтенд позади, переходим к бекенду — секции-рекордсмену по количеству баззвордов.
Казалось бы, простой вопрос: может ли среда CLR вызвать финализатор объекта, когда экземплярный метод не завершил свое исполнение? Читать полностью »
→ Часть 1: Как работает JS: обзор движка, механизмов времени выполнения, стека вызовов
→ Часть 2: Как работает JS: о внутреннем устройстве V8 и оптимизации кода
В третьем материале из серии, которая посвящена особенностям работы JavaScript, мы поговорим о памяти. Эта тема крайне важна, однако, разработчики нередко игнорируют её. В основе этой ситуации лежат разные причины, среди которых — всё возрастающая сложность современных языков программирования и прогресс в развитии средств автоматического управления памятью. Помимо рассказа о модели памяти JS, мы поделимся с вами несколькими советами, направленными на борьбу с утечками памяти.
По словам автора статьи, в компании SessionStack используют приёмы предотвращения утечек памяти для того, чтобы не допустить неоправданно высокого потребления памяти в веб-приложениях, в которые интегрированы их разработки.
Читать полностью »
Эта статья — продолжение, начало здесь. Для тех, кто не кликнул на ссылку, краткая вводная:
Мы обсуждаем сборку мусора в операционной системе Фантом, то есть в среде виртуальной (байткод-) машины, работающей в персистентной оперативной памяти. Размер персистентной памяти — порядка размера диска, то есть единицы терабайт на сегодня и, потенциально, десятки и сотни терабайт завтра.
Поскольку речь идёт о виртуальной памяти, то существенная часть объектов в любом случае находится не в оперативной памяти, независимо от того, какой алгоритм и вообще подход мы избрали. То есть — стоимость доступа к объекту велика. Это, в общем случае, дисковая операция.
Кроме того, следует ожидать, что в сетевой среде совокупности таких виртуальных машин будут обмениваться прокси-объектами, то есть будет существовать граф объектов, растянутый на много машин в сети и, конечно, во всём этом кошмаре потенциально потребуется уметь собирать мусор не только на одной машине, но и по сети.
Принятая мной идея схемы сборки мусора в такой среде выглядит как совокупность двух сборщиков.
Читать полностью »
В этой статье мы рассмотрим распространённые виды утечек памяти в клиентском JavaScript. Также мы узнаем, как их обнаружить с помощью Chrome Development Tools.
Привет всем. Продолжу о Фантоме. Для понимания полезно прочесть статью про персистентную оперативку, а так же общую статью про Фантом на Открытых Системах. Но можно и так.
Итак, мы имеем ОС (или просто среду, не важно), которая обеспечивает прикладным программам персистентную оперативную память, и вообще персистентную «жизнь». Программы живут в общем адресном пространстве с управляемыми (managed) пойнтерами, объектной байткод-машиной, не замечают рестарта ОС и, в целом, счастливы.
Очевидно, что такой среде нужна сборка мусора. Но — какая?
Есть несколько проблем, навязанных спецификой.
Во-первых, теоретически, объём виртуальной памяти в такой среде огромен — терабайты, всё содержимое диска. Ведь мы отображаем в память всё и всегда.
Во-вторых, нас категорически не устраивают stop the world алгоритмы. Если для обычного процесса остановка в полсекундны может быть приемлема, то для виртуальной памяти, которая, большей частью, на диске, это будут уже полчаса, а то как бы не полсуток!
Наконец, если считать, что полная сборка мусора составляет полсуток, нас, наверное, это не устроит — было бы здорово иметь какой-то быстрый процесс сбора мусора, хотя бы и не полностью честный, пусть он часть мусора теряет, но если удаётся быстро вернуть 90% — уже хорошо.
Тут нужна оговорка. Вообще говоря, в системе, которая располагает парой терабайт виртуальной памяти, это не так уж критично — даже если не делать освобождение памяти полсуток, возможно, не так много и набежит — ну, например, истратится 2-3, ну 5 гигабайт, ну даже и 50 гигабайт — не жалко, диск большой.
Но, скорее всего, это приведёт к большой фрагментации памяти — множество локальных переменных окажутся раскиданы по многим далеко расположенным страницам, при этом высока вероятность того, что небольшие вкрапления актуальной информации будут перемежены с тоннами неактуального мусора, что сильно повысит нагрузку на оперативную память.
Ок, итого у нас две задачи.
Читать полностью »
