Рубрика «сборка мусора»

Как работает память в Python - 1

Что такое память и зачем она нужна?

Читать полностью »

В прошлом году Mozilla выпустила Quantum CSS для Firefox, который стал кульминацией восьми лет разработки Rust — безопасного для памяти языка системного программирования. Потребовалось более года, чтобы переписать основной компонент браузера на Rust.

До сих пор все основные браузерные движки написаны на C++, в основном по соображениям эффективности. Но с большой производительностью приходит большая ответственность: программисты C++ должны вручную управлять памятью, что открывает ящик Пандоры уязвимостей. Rust не только устраняет такие ошибки, но его методы также предотвращают гонки данных, позволяя программистам более эффективно внедрять параллельный код.

Бесстрашная защита. Безопасность памяти в Rust - 1

Читать полностью »

Менеджмент, тестирование и фронтенд позади, переходим к бекенду — секции-рекордсмену по количеству баззвордов.

image
Читать полностью »

Казалось бы, простой вопрос: может ли среда CLR вызвать финализатор объекта, когда экземплярный метод не завершил свое исполнение? Читать полностью »

→ Часть 1: Как работает JS: обзор движка, механизмов времени выполнения, стека вызовов
→ Часть 2: Как работает JS: о внутреннем устройстве V8 и оптимизации кода

В третьем материале из серии, которая посвящена особенностям работы JavaScript, мы поговорим о памяти. Эта тема крайне важна, однако, разработчики нередко игнорируют её. В основе этой ситуации лежат разные причины, среди которых — всё возрастающая сложность современных языков программирования и прогресс в развитии средств автоматического управления памятью. Помимо рассказа о модели памяти JS, мы поделимся с вами несколькими советами, направленными на борьбу с утечками памяти.

Как работает JS: управление памятью, четыре вида утечек памяти и борьба с ними - 1

По словам автора статьи, в компании SessionStack используют приёмы предотвращения утечек памяти для того, чтобы не допустить неоправданно высокого потребления памяти в веб-приложениях, в которые интегрированы их разработки.
Читать полностью »

Эта статья — продолжение, начало здесь. Для тех, кто не кликнул на ссылку, краткая вводная:

Мы обсуждаем сборку мусора в операционной системе Фантом, то есть в среде виртуальной (байткод-) машины, работающей в персистентной оперативной памяти. Размер персистентной памяти — порядка размера диска, то есть единицы терабайт на сегодня и, потенциально, десятки и сотни терабайт завтра.

Поскольку речь идёт о виртуальной памяти, то существенная часть объектов в любом случае находится не в оперативной памяти, независимо от того, какой алгоритм и вообще подход мы избрали. То есть — стоимость доступа к объекту велика. Это, в общем случае, дисковая операция.

Кроме того, следует ожидать, что в сетевой среде совокупности таких виртуальных машин будут обмениваться прокси-объектами, то есть будет существовать граф объектов, растянутый на много машин в сети и, конечно, во всём этом кошмаре потенциально потребуется уметь собирать мусор не только на одной машине, но и по сети.

Принятая мной идея схемы сборки мусора в такой среде выглядит как совокупность двух сборщиков.
Читать полностью »

В этой статье мы рассмотрим распространённые виды утечек памяти в клиентском JavaScript. Также мы узнаем, как их обнаружить с помощью Chrome Development Tools.

timeline в Chrome Dev Tools

Читать полностью »

Привет всем. Продолжу о Фантоме. Для понимания полезно прочесть статью про персистентную оперативку, а так же общую статью про Фантом на Открытых Системах. Но можно и так.

Итак, мы имеем ОС (или просто среду, не важно), которая обеспечивает прикладным программам персистентную оперативную память, и вообще персистентную «жизнь». Программы живут в общем адресном пространстве с управляемыми (managed) пойнтерами, объектной байткод-машиной, не замечают рестарта ОС и, в целом, счастливы.

Очевидно, что такой среде нужна сборка мусора. Но — какая?

Есть несколько проблем, навязанных спецификой.

Во-первых, теоретически, объём виртуальной памяти в такой среде огромен — терабайты, всё содержимое диска. Ведь мы отображаем в память всё и всегда.

Во-вторых, нас категорически не устраивают stop the world алгоритмы. Если для обычного процесса остановка в полсекундны может быть приемлема, то для виртуальной памяти, которая, большей частью, на диске, это будут уже полчаса, а то как бы не полсуток!

Наконец, если считать, что полная сборка мусора составляет полсуток, нас, наверное, это не устроит — было бы здорово иметь какой-то быстрый процесс сбора мусора, хотя бы и не полностью честный, пусть он часть мусора теряет, но если удаётся быстро вернуть 90% — уже хорошо.

Тут нужна оговорка. Вообще говоря, в системе, которая располагает парой терабайт виртуальной памяти, это не так уж критично — даже если не делать освобождение памяти полсуток, возможно, не так много и набежит — ну, например, истратится 2-3, ну 5 гигабайт, ну даже и 50 гигабайт — не жалко, диск большой.

Но, скорее всего, это приведёт к большой фрагментации памяти — множество локальных переменных окажутся раскиданы по многим далеко расположенным страницам, при этом высока вероятность того, что небольшие вкрапления актуальной информации будут перемежены с тоннами неактуального мусора, что сильно повысит нагрузку на оперативную память.

Ок, итого у нас две задачи.
Читать полностью »

Большинство разработчиков воспринимают сборку мусора (garbage collection) как нечто само собой разумеющееся. Это стандартный процесс, который периодически освобождает память, удаляя ненужные объекты. А вот американский программист Кен Фокс (Ken Fox) захотел досконально разобраться и заглянуть «под капот» современных сборщиков мусора.

Кен «поигрался» с пятью разными алгоритмами сборки мусора и опубликовал маленькие анимации, которые наглядно демонстрируют их работу.

Анимации большего размера выложены на github.com/kenfox/gc-viz.
Читать полностью »

Коити: Порог срабатывания сборщика мусора в Ruby — 8 МБ. Почему используется такое маленькое значение?
Matz: Потому что 20 лет назад я работал на машине с 10 МБ памяти.

Вопрос производительности всегда был одним из наиболее обсуждаемых и актуальных в Ruby-сообществе. Будь то высоконагруженный веб-сайт или простой скрипт по бекапу данных — скорость работы является их важнейшей характеристикой. При этом знание возможностей и ограничений языка разработки зачастую служит важным источником идей для оптимизации, позволяет «выжать» максимум из системы.

В статье речь пойдет об одной из наиболее сильно влияющих на производительность частей языка Ruby — сборщике мусора, алгоритмах его работы и улучшениях, внесенных в его работу в последних версиях языка. Речь пойдет о наиболее распространенной, «канонической» реализации Ruby — так называемой MRI или CRuby.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js